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 <smyslov.ietf@gmail.com> 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
> >