[IPsec] New version: draft-ietf-ipsecme-tcp-encaps-05
Hello, I've uploaded a new version of the TCP Encapsulation draft that is in WG last call, incorporating the feedback from Tero and Valery. Please take another read through, and let me know your feedback and if you think we want any more changes to the document. Thanks! Tommy > On Jan 23, 2017, at 1:59 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions of > the IETF. > >Title : TCP Encapsulation of IKE and IPsec Packets >Authors : Tommy Pauly > Samy Touati > Ravi Mantha > Filename: draft-ietf-ipsecme-tcp-encaps-05.txt > Pages : 21 > Date: 2017-01-23 > > Abstract: > This document describes a method to transport IKE and IPsec packets > over a TCP connection for traversing network middleboxes that may > block IKE negotiation over UDP. This method, referred to as TCP > encapsulation, involves sending both IKE packets for tunnel > establishment as well as tunneled packets using ESP over a TCP > connection. This method is intended to be used as a fallback option > when IKE cannot be negotiated over UDP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : TCP Encapsulation of IKE and IPsec Packets Authors : Tommy Pauly Samy Touati Ravi Mantha Filename: draft-ietf-ipsecme-tcp-encaps-05.txt Pages : 21 Date: 2017-01-23 Abstract: This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for tunnel establishment as well as tunneled packets using ESP over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04
Hi Tommy, > >> Actually Valery did raise good point, that for IKE this might cause > >> issues. > >> > >> Now when I am thinking about this, I think that for IKE packets the > >> response to the IKE request should go to the same TCP session where > >> the request came in. This would be aligned with the RFC7296 which says > >> you reverse ip-addresses and ports for incoming IKE request, and reply > >> to that address. > > > > That makes sense. > > > >> For new requests the IKE should use the same TCP session than what is > >> being used for ESP, i.e., the most fresh one. > >> > >> The most fresh should then be defined as the one which has received > >> ESP sequence number which is not out of order (note, that there might > >> be multipe ESP SAs in the same TCP connection, so largest sequence > >> number is not right way to express this), or which has received new > >> IKE request (note, not IKE respose, or retrasmitted request) last. > > > > It doesn't really help to prevent attack, but unnecessary complicates > > implementations. > > I'd rather suggest to choose the TCP connection over which the latest > > valid ESP or IKE packet (that is not a retransmission) is received. > > Right, so how about we say that a packet that causes the responder to choose > which TCP connection to > use must be: > - A valid IKE or ESP message that can be successfully decrypted and > authenticated > - Not a retransmission > - Not outside of the ESP replay window Technically this requirement is wrong, since every ESP packet with SN greater than the highest seen so far will be outside ESP replay window (and will update this window if the packet is decrypted and verified successfully). > - In order for the sequence of message IDs for that SA > > Does that work to sufficiently be conservative about which packets to trust, > while not adding undue > complication? I think that it is enough if this is a valid (one that passed a replay check, then successfully decrypted and authenticated) ESP packet or IKE message that is most recently received. This rule would avoid all complexities concerned with determining the highest SN for many ESP connections over single TCP. In normal cases (no attack) the most recently received ESP packet will always have the highest SN if TCP encapsulation is employed. In case of attack that Tero described the attacker must be on the path and there is no defense against she anyway, so no need to complicate the responder. It is also a good thing to advise, that for TCP encapsulation ESP replay window size should be set to 0 (since TCP doesn't allow reordered packets). Regards, Valery. > Thanks, > Tommy > > > > > In most cases this is equivalent to the rules you suggests > > (since TCP prevents reordering the latest packet will have > > the highest SN/MID). In case of powerful attacker on the path, > > who can steal, drop, modify and replay packets, the rules > > you suggest won't help anyway. > > > > Regards, > > Valery. > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
