Two comments: 1. The draft seems to imply that only tunnel initiator is allowed to initiate TCP session, however what is behavior after TCP connection is lost and initiator need to re-create it? does it do it right away or only re-create TCP session when initiator need to send some packet? I assume it should be right away, because otherwise there will be traffic loss if the responder need to send packet before the TCP session is re-created; So if my above understanding is correct, I'd like draft to clearly state the behavior;
2. section 6 mention that implementation should be able to receive from any TCP session and not enforcing any strict mapping; that's fine for receiving, however for sending traffic, system (specially responder) still need to know which TCP session to use to reach peer of a given SA; for example, If NAT is detected, then in case of TCP session is lost on initiator side but still exists on responder side and initiator re-create the TCP session, the new TCP session might have a different NAT public port or even different NAT public address, so the responder can't tell if the new TCP session is for an existing SA or a new tunnel, this means initiator need to send message for all existing SA that need to use the new TCP session so that responder could update its SA-to-TCP session mapping because otherwise responder might use the old TCP session for outgoing traffic of existing SA and traffic will be blackholed; in section 6, draft states that either UPDATE_SA_ADDRESS or a IKE keepalive could be used, however there is no specification of behavior for updating CHILD_SA mapping when MOBIKE is not supported; maybe initiator should send some kind of dummy packet over the CHILD_SA to update responder's mapping? > -----Original Message----- > From: IPsec [mailto:[email protected]] On Behalf Of Tommy Pauly > Sent: Monday, October 31, 2016 9:01 AM > To: IPsecME WG > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt > > Hello, > > I’ve posted a new version of the TCP encapsulation draft with the following > changes: > > 1. Added a section to explicitly discuss how to fallback from UDP to TCP > (retransmissions, etc) based on feedback from the charter discussion 2. > Explained that this method of encapsulation can be used for any stream > protocol, and is not TCP specific, based on feedback from the charter > discussion 3. Clarified the use of multiple TCP connections for Child SAs, > based on Jun Hu’s questions > > Also, I’m happy to say that we’ve been doing interoperability testing between > Apple clients and Cisco server for TCP encapsulation. If anyone else has an > implementation they’d like to try out, please let us know! > > Best, > Tommy > > > On Oct 31, 2016, at 8:56 AM, [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-03.txt > > Pages : 20 > > Date : 2016-10-31 > > > > 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-03 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-03 > > > > > > 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
