I agree with Valery that there doesn't seem to be any problem here. The statement that the initiator is "creating a TCP-3 for SA-2" is not a scenario that we want to support, because there is not strict mapping between TCP connections and SAs. The responder can respond to both SAs on the same TCP connection, or it may not. Both sides should support any combination, and any implementation that refuses to accept packets will not be compliant with the spec.
Thanks, Tommy > On Nov 15, 2016, at 11:18 AM, Valery Smyslov <[email protected]> wrote: > > What’s wrong with that? > > As far as I understand the draft, the mapping between IKE/IPsec and TCP is > loose, > so it seems that such a scenario is OK (Tommy corrects me if I’m wrong). > Do you have any problems with it? > > > > > From: Hu, Jun (Nokia - US) <mailto:[email protected]> > Sent: 15 ноября 2016 г. 10:48 > To: Valery Smyslov <mailto:[email protected]>; Tommy Pauly > <mailto:[email protected]>; IPsecME WG <mailto:[email protected]> > Subject: RE: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt > > However since the draft allows multiple TCP connections for the same tunnel; > think of a case like following: > A tunnel has two CHILD_SA, each has its own TCP connection; SA-1 has TCP-1, > SA-2 has TCP-2; > For some reason TCP-2 goes down on initiator side (TCP-1 is still up), so > initiator create a TCP-3, for SA-2, if initiator only send IKE keepalive to > update responder, so responder will change both SA-1 and SA-2 to TCP-3? > > From: IPsec [mailto:[email protected]] On Behalf Of Valery Smyslov > Sent: Monday, November 14, 2016 1:36 PM > To: Hu, Jun (Nokia - US); Tommy Pauly; IPsecME WG > Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt > > Hi Jun, > > for the second part: your IKE SA must be linked to all child SAs > it created (in other words, child SAs must remember which IKE SA > created them and visa versa, otherwise a lot of IKEv2 logic > doesn’t work). So there is no need to send packets over all > child SAs, it’s enough to send liveness check over IKE SA, > so that responder learn new TCP-IKE mapping and use it > for linked child SAs as well. > > Regards, > Valery. > > > From: Hu, Jun (Nokia - US) <mailto:[email protected]> > Sent: 14 ноября 2016 г. 22:21 > To: Tommy Pauly <mailto:[email protected]>; IPsecME WG <mailto:[email protected]> > Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt > > 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] <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] > > > <mailto:[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/ > > > <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 > > > <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 > > > <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/ <ftp://ftp.ietf.org/internet-drafts/> > > > > > > _______________________________________________ > > > IPsec mailing list > > > [email protected] <mailto:[email protected]> > > > https://www.ietf.org/mailman/listinfo/ipsec > > > <https://www.ietf.org/mailman/listinfo/ipsec> > > > > _______________________________________________ > > IPsec mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/ipsec > > <https://www.ietf.org/mailman/listinfo/ipsec> > _______________________________________________ > IPsec mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec> > > > _______________________________________________ > IPsec mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec>
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
