Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt
Hi Tommy, > I agree with the points you bring up for MOBIKE (not changing the message ID, > and needing to recalculate > NAT detection payloads). Those are useful to clarify. > > Regarding retransmissions/puzzles/error handling, I agree with Paul that the > recommendations being > provided in your draft are potentially harmful to interoperability. We > specifically did not include those in > RFC8229 because it is not only possible, but likely, that some deployments > will use TCP as a proxying layer > that’s not directly implemented on the IKE endpoint, and that the IKE > messages may be sometimes > transmitted over both UDP and TCP (UDP behind TCP). This is, in fact, how we > did our initial testing and > bringup of the functionality. Yes, I assumed that TCP is end-to-end. > Not retransmitting (or the other examples) assumes that the reliable link is > end-to-end, even though that is > not guaranteed or required by the spec. Can you clarify why an implementation > would require modification of > the protocol such that TCP encapsulation could not occur in a proxy? The one > case I see is client-side MOBIKE, > but I don’t think the server needs to do anything special (and clients that > don’t want to do fancy MOBIKE > fallback between UDP and TCP don’t need to change). Let's first clarify what TCP proxy is. I can imagine a four different scenarios ( <-> means UDP traffic, <=> means TCP traffic): 1. UDP IKEv2 Initiator <-> TCP Proxy 1 <=> TCP Proxy 2 <-> UDP IKEv2 Responder In this case both IKEv2 implementations see only UDP traffic, so recommendations given in the draft are not applicable. 2. TCP IKEv2 Initiator <=> TCP IKEv2 Responder In this case there are no TCP proxies at all, this is the case that is assumed in the draft. 3. TCP IKEv2 Initiator <=> TCP Proxy <-> UDP IKEv2 Responder 4. UDP IKEv2 Initiator <-> TCP Proxy <=> TCP IKEv2 Responder These are the cases where problems might arise. In particular: a. NAT_DETECTION_*_IP content won't match, so there will always be "false positive" detection of NAT. b. In case 4 if TCP session is broken for any reason, then it is the Initiator's responsibility to restore it. However, in this case Initiator is not aware of the presence of TCP, so if it has no traffic to send, the TCP connection will remain broken. If the responder during that period needs to send something to the Initiator (say, to rekey SA), it will fail and the SA will be deleted, causing de-synchronization between the peers. c. Multihomed MOBIKE scenarios won't work (unless proxy is co-located on the same host with IKEv2). d. There may be some issues with transport mode, because it is assumed that the IPsec SA is between IKE peers, and the "peers" will be different in case of TCP and UDP (unless proxy is co-located on the same host with IKEv2). Am I missing something? BTW, if you assume that the TCP proxy is always co-located on the same host with UDP IKEv2 implementation, then we can assume that the UDP link proxy <-> IKEv2 is reliable (the packets don't leave the host), so recommendations given in the draft (no retransmissions etc.) won't harm. Regards, Valery. > Thanks, > Tommy > > > On Sep 7, 2018, at 7:18 AM, Valery Smyslov wrote: > > > > Hi Paul, > > > >>> I've posted a draft with clarifications and implementation guidelines > >>> for RFC8229. These clarifications and recommendations are based > >>> on experience of implementing TCP encapsulation and testing it in > >>> various IKEv2 scenarios. > >>> > >>> Feedback of any sort is highly appreciated. > >> > >> I would cut a lot of the introduction / abstract and come straight to > >> the point. Simiarly, further one not provide as much details and just > >> come to the point faster. > > > > I tried to be pedant :-) > > > >> I don't see any consideration in the document about deployments that > >> use a TCP proxy in front of the IKE daemon. In those scenarios, the > >> daemon might not even know TCP is used or the proxy code is written in > >> a way that only minimal changes to the IKEv2 core are needed. > > > > Is it ever possible? My experience shows that adding TCP encapsulation > > influences IKEv2 code pretty highly. > > > >> So a lot of decisions you specify, such as not sending retransmits, might > >> not > >> be possible for those kind of implementations, and so this document > >> dictating them for make interop harder, not easier. > > > > Why? Can you clarify in which cases interop will be harder? > > > >> As this also touches on message IDs, and I think we might have some > >> msgid deadlocks even in the UDP only case, perhaps a clarifying > > > > If you mean MOBIKE, I agree with you that deadlocks seem to be possible. > > > >> document could add some non-TCP items as well? And the TCP part could > >> be part of the new clarification draft ? > > > > Not sure it's worth to mix them. > > > > Regards, > > Valery. > > > >> > >> Paul > >> > >>
Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt
Hi Valery, Thanks for sharing this! I agree with the points you bring up for MOBIKE (not changing the message ID, and needing to recalculate NAT detection payloads). Those are useful to clarify. Regarding retransmissions/puzzles/error handling, I agree with Paul that the recommendations being provided in your draft are potentially harmful to interoperability. We specifically did not include those in RFC8229 because it is not only possible, but likely, that some deployments will use TCP as a proxying layer that’s not directly implemented on the IKE endpoint, and that the IKE messages may be sometimes transmitted over both UDP and TCP (UDP behind TCP). This is, in fact, how we did our initial testing and bringup of the functionality. Not retransmitting (or the other examples) assumes that the reliable link is end-to-end, even though that is not guaranteed or required by the spec. Can you clarify why an implementation would require modification of the protocol such that TCP encapsulation could not occur in a proxy? The one case I see is client-side MOBIKE, but I don’t think the server needs to do anything special (and clients that don’t want to do fancy MOBIKE fallback between UDP and TCP don’t need to change). Thanks, Tommy > On Sep 7, 2018, at 7:18 AM, Valery Smyslov wrote: > > Hi Paul, > >>> I've posted a draft with clarifications and implementation guidelines >>> for RFC8229. These clarifications and recommendations are based >>> on experience of implementing TCP encapsulation and testing it in >>> various IKEv2 scenarios. >>> >>> Feedback of any sort is highly appreciated. >> >> I would cut a lot of the introduction / abstract and come straight to >> the point. Simiarly, further one not provide as much details and just >> come to the point faster. > > I tried to be pedant :-) > >> I don't see any consideration in the document about deployments that >> use a TCP proxy in front of the IKE daemon. In those scenarios, the >> daemon might not even know TCP is used or the proxy code is written in >> a way that only minimal changes to the IKEv2 core are needed. > > Is it ever possible? My experience shows that adding TCP encapsulation > influences IKEv2 code pretty highly. > >> So a lot of decisions you specify, such as not sending retransmits, might not >> be possible for those kind of implementations, and so this document >> dictating them for make interop harder, not easier. > > Why? Can you clarify in which cases interop will be harder? > >> As this also touches on message IDs, and I think we might have some >> msgid deadlocks even in the UDP only case, perhaps a clarifying > > If you mean MOBIKE, I agree with you that deadlocks seem to be possible. > >> document could add some non-TCP items as well? And the TCP part could >> be part of the new clarification draft ? > > Not sure it's worth to mix them. > > Regards, > Valery. > >> >> Paul >> >> ___ >> 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
Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt
Hi Paul, > > I've posted a draft with clarifications and implementation guidelines > > for RFC8229. These clarifications and recommendations are based > > on experience of implementing TCP encapsulation and testing it in > > various IKEv2 scenarios. > > > > Feedback of any sort is highly appreciated. > > I would cut a lot of the introduction / abstract and come straight to > the point. Simiarly, further one not provide as much details and just > come to the point faster. I tried to be pedant :-) > I don't see any consideration in the document about deployments that > use a TCP proxy in front of the IKE daemon. In those scenarios, the > daemon might not even know TCP is used or the proxy code is written in > a way that only minimal changes to the IKEv2 core are needed. Is it ever possible? My experience shows that adding TCP encapsulation influences IKEv2 code pretty highly. > So a lot of decisions you specify, such as not sending retransmits, might not > be possible for those kind of implementations, and so this document > dictating them for make interop harder, not easier. Why? Can you clarify in which cases interop will be harder? > As this also touches on message IDs, and I think we might have some > msgid deadlocks even in the UDP only case, perhaps a clarifying If you mean MOBIKE, I agree with you that deadlocks seem to be possible. > document could add some non-TCP items as well? And the TCP part could > be part of the new clarification draft ? Not sure it's worth to mix them. Regards, Valery. > > Paul > > ___ > 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
Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt
On Fri, 7 Sep 2018, Valery Smyslov wrote: I've posted a draft with clarifications and implementation guidelines for RFC8229. These clarifications and recommendations are based on experience of implementing TCP encapsulation and testing it in various IKEv2 scenarios. Feedback of any sort is highly appreciated. I would cut a lot of the introduction / abstract and come straight to the point. Simiarly, further one not provide as much details and just come to the point faster. I don't see any consideration in the document about deployments that use a TCP proxy in front of the IKE daemon. In those scenarios, the daemon might not even know TCP is used or the proxy code is written in a way that only minimal changes to the IKEv2 core are needed. So a lot of decisions you specify, such as not sending retransmits, might not be possible for those kind of implementations, and so this document dictating them for make interop harder, not easier. As this also touches on message IDs, and I think we might have some msgid deadlocks even in the UDP only case, perhaps a clarifying document could add some non-TCP items as well? And the TCP part could be part of the new clarification draft ? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt
Hi, I've posted a draft with clarifications and implementation guidelines for RFC8229. These clarifications and recommendations are based on experience of implementing TCP encapsulation and testing it in various IKEv2 scenarios. Feedback of any sort is highly appreciated. Regards, Valery. > -Original Message- > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > Sent: Friday, September 07, 2018 3:42 PM > To: Valery Smyslov > Subject: New Version Notification for > draft-smyslov-ipsecme-tcp-guidelines-00.txt > > > A new version of I-D, draft-smyslov-ipsecme-tcp-guidelines-00.txt > has been successfully submitted by Valery Smyslov and posted to the > IETF repository. > > Name: draft-smyslov-ipsecme-tcp-guidelines > Revision: 00 > Title:Clarifications and Implementation Guidelines for using > TCP Encapsulation in IKEv2 > Document date:2018-09-07 > Group:Individual Submission > Pages:8 > URL: > https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-tcp-guidelines-00.txt > Status: > https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-tcp-guidelines/ > Htmlized: > https://tools.ietf.org/html/draft-smyslov-ipsecme-tcp-guidelines-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-smyslov-ipsecme-tcp-guidelines > > > Abstract: >The Internet Key Exchange Protocol version 2 (IKEv2) defined in >[RFC7296] uses UDP transport for its messages. [RFC8229] specifies a >way to encapsulate IKEv2 and ESP (Encapsulating Security Payload) >messages in TCP, thus making possible to use them in network >environments that block UDP traffic. However, some nuances of using >TCP in IKEv2 are not covered by that specification. This document >provides clarifications and implementation guidelines for [RFC8229]. > > > > > 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. > > The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
