Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt
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) Sent: 15 ноября 2016 г. 10:48 To: Valery Smyslov; Tommy Pauly; IPsecME WG 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:ipsec-boun...@ietf.org] 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) Sent: 14 ноября 2016 г. 22:21 To: Tommy Pauly; IPsecME WG 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:ipsec-boun...@ietf.org] 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, 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 Man
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:ipsec-boun...@ietf.org] 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, 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-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 > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > ___ > 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-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, 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-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 > 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-03.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-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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
