• sewookseo's avatar
    net: Find dst with sk's xfrm policy not ctl_sk · e22aa148
    sewookseo authored
    If we set XFRM security policy by calling setsockopt with option
    IPV6_XFRM_POLICY, the policy will be stored in 'sock_policy' in 'sock'
    struct. However tcp_v6_send_response doesn't look up dst_entry with the
    actual socket but looks up with tcp control socket. This may cause a
    problem that a RST packet is sent without ESP encryption & peer's TCP
    socket can't receive it.
    This patch will make the function look up dest_entry with actual socket,
    if the socket has XFRM policy(sock_policy), so that the TCP response
    packet via this function can be encrypted, & aligned on the encrypted
    TCP socket.
    
    Tested: We encountered this problem when a TCP socket which is encrypted
    in ESP transport mode encryption, receives challenge ACK at SYN_SENT
    state. After receiving challenge ACK, TCP needs to send RST to
    establish the socket at next SYN try. But the RST was not encrypted &
    peer TCP socket still remains on ESTABLISHED state.
    So we verified this with test step as below.
    [Test step]
    1. Making a TCP state mismatch between client(IDLE) & server(ESTABLISHED).
    2. Client tries a new connection on the same TCP ports(src & dst).
    3. Server will return challenge ACK instead of SYN,ACK.
    4. Client will send RST to server to clear the SOCKET.
    5. Client will retransmit SYN to server on the same TCP ports.
    [Expected result]
    The TCP connection should be established.
    
    Cc: Maciej Żenczykowski <maze@google.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Sehee Lee <seheele@google.com>
    Signed-off-by: default avatarSewook Seo <sewookseo@google.com>
    Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    e22aa148
ip_output.c 43.5 KB