Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt

[Tommy Pauly <[e-mail]>]

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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
>