Hi Tommy, I think the new text substantially simplifies implementations.
Thank you, Valery. > Hello all, > > I've updated the TCP Encapsulation draft with new recommendations around > handling the mapping > between IKE SAs and TCP Connections based on the conversation at the Seoul > meeting. The relevant new > text in section 6 is: > > > An initiator SHOULD only open one TCP connection per IKE SA, over > which it sends all of the corresponding IKE and ESP messages. This > helps ensure that any firewall or NAT mappings allocated for the TCP > connection apply to all of the traffic associated with the IKE SA > equally. > > A responder SHOULD at any given time send packets for an IKE SA and > its Child SAs over only one TCP connection. It should choose the TCP > connection on which it last received a valid and decryptable IKE or > ESP message. Since a connection may be broken and a new connection > re-established by the initiator without the responder being aware, a > responder SHOULD accept receiving IKE and ESP messages on a new > connection. It will then use that connection for all subsequent > responses. A responder MAY close a TCP connection that it perceives > as idle and extraneous (one previously used for IKE and ESP messages > that has been replaced by a new connection). > > Multiple IKE SAs SHOULD NOT share a single TCP connection. > > Please respond to indicate your thoughts on this! > > Thanks, > Tommy > > > > On Dec 4, 2016, at 3:04 PM, [email protected] 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-04.txt > > Pages : 21 > > Date : 2016-12-04 > > > > 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-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-04 > > > > > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
