> On Apr 26, 2017, at 2:58 PM, Spencer Dawkins at IETF > <spencerdawkins.i...@gmail.com> wrote: > > Hi, Ben and Tommy, > > On Wed, Apr 26, 2017 at 1:36 PM, Ben Campbell <b...@nostrum.com> wrote: > > > On Apr 26, 2017, at 12:50 PM, Tommy Pauly <tpa...@apple.com> wrote: > > > > Hi Ben, > > > > Thanks for the comments! Your point about the line in Section 6 not making > > sense is definitely a good point. How about this text (changes in bold): > > > > If a TCP connection is being used to resume a previous IKE session, > > the TCP Responder can recognize the session using either the IKE SPI > > from an encapsulated IKE message or the ESP SPI from an encapsulated > > ESP message. If the session had been fully established previously, > > it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES > > message if MOBIKE is supported, or an INFORMATIONAL message (a > > keepalive) otherwise. [The TCP Responder MUST NOT accept any messages > > for the existing IKE session on new an incoming connection unless that > > connection > > begins with the stream prefix. If either the TCP Originator or TCP > > Responder > > cannot parse valid IKE or ESP messages on a TCP encapsulation connection > > that was started with a valid stream prefix, it MUST close the TCP > > connection.] > > If there is instead a syntax issue within an IKE > > message, an implementation MUST send the INVALID_SYNTAX notify > > payload and tear down the IKE SA as usual, rather than tearing down > > the TCP connection directly. > > > > Thanks, > > Tommy > > That looks good to me. I will clear, with the assumption this or similar > edits will make it into the draft. > > Does > > The TCP Responder MUST NOT accept any messages > for the existing IKE session on new an incoming connection unless that > connection > begins with the stream prefix. > > parse for you guys? I get stuck at "on new an incoming”.
I’m guessing that’s an edit-o from. Maybe it should be “on a new incoming”? > > Spencer > > > Thanks! > > Ben. > > > > > >> On Apr 26, 2017, at 8:35 AM, Ben Campbell <b...@nostrum.com> wrote: > >> > >> By the way, the DISCUSS vs COMMENT framing has gotten lost from the > >> thread. Only the first point was part of the DISCUSS, the rest are > >> non-binding comments. And I think the DISCUSS point is moving in the right > >> direction, pending a text proposal. > >> > >> Thanks! > >> > >> Ben. > >> > >>> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty > >>> <kathleen.moriarty.i...@gmail.com> wrote: > >>> > >>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell <b...@nostrum.com> wrote: > >>>> > >>>>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty > >>>>> <kathleen.moriarty.i...@gmail.com> wrote: > >>>>> > >>>>> Thanks for the quick response Paul, a few questions... > >>>>> > >>>>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters <p...@nohats.ca> wrote: > >>>>>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote: > >>>>>> > >>>>>>>> IIUC, the entire point of having the stream prefix is to allow the > >>>>>>>> TCP > >>>>>>>> responder to demux between this protocol, and some other protocol > >>>>>>>> that > >>>>>>>> would normally run on that port. Saying it MUST close the TCP session > >>>>>>>> seems to completely remove that value. I assume people meant to > >>>>>>>> allow the > >>>>>>>> respondent to delegate a stream out to some other protocol handler > >>>>>>>> if the > >>>>>>>> prefix is not present? > >>>>>>>> > >>>>>>> > >>>>>>> I believe that this is because there is presumed to be no other > >>>>>>> service operating on the listening port (assuming a VPN concentrator), > >>>>>>> but that's not explicitly stated either. > >>>>>> > >>>>>> > >>>>>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer one > >>>>>> of > >>>>>> the other kinds of SSL VPNs or as the administration interface or > >>>>>> user interface. > >>>>> > >>>>> OK, sounds like I didn't help here, so the editors should propose text > >>>>> to address this gap. > >>>> > >>>> I think we are on the right track here, pending proposed text. > >>>> > >>>>> > >>>>>> > >>>>>>>> -- 2nd to last paragraph: "This document leaves the selection of TCP > >>>>>>>> ports up to implementations." > >>>>>>>> I suspect "configurable local policy" would make more sense. Leaving > >>>>>>>> it > >>>>>>>> up to "implementations" leaves open the chance of different > >>>>>>>> implementations making non-intersecting port choices, which doesn't > >>>>>>>> help > >>>>>>>> interoperability. > >>>>>>> > >>>>>>> > >>>>>>> This may go more into unexplained assumptions... the clients > >>>>>>> authorized to connect to the server would need to know the correct > >>>>>>> port to establish a session and would be given that information > >>>>>>> specific to the implementation. With this assumption, the above > >>>>>>> should be fine... but editors/AD/WG, please correct me if I am wrong. > >>>>>> > >>>>>> > >>>>>> I am pretty sure what is meant is "configuration" and not > >>>>>> "implementation". > >>>>> > >>>>> Is that in response to me being wrong in my assumption or the draft > >>>>> should say configuration (I think it's the latter, but important to > >>>>> check)? > >>>> > >>>> We are probably splitting hairs on the meaning of “implementation” vs > >>>> “configuration”. (and maybe “deployment”). I was thinking of > >>>> “implementation” as being what developers do, and > >>>> “configuring/deploying” as what operators do. But I am aware that > >>>> operators sometimes talk about “implementing” a system. > >>>> > >>>> So my point was that I assume for purposes of interoperability that a > >>>> general purpose client or server would allow the port to be changed in > >>>> the field. > >>>> > >>>>> > >>>>>> > >>>>>>>> -4, first paragraph: What is the expected behavior from a peers that > >>>>>>>> do > >>>>>>>> not support this spec when they receive a TCP stream with the magic > >>>>>>>> number on a port for some other protocol? > >>>>>>> > >>>>>>> > >>>>>>> Maybe listing assumptions up front in the draft would help _IF_ the > >>>>>>> assumption is that the listening server is a VPN concentrator that > >>>>>>> wouldn't be listening for other services. > >>>>>> > >>>>>> > >>>>>> Support for TCP would be based on preconfiguration, so the client knows > >>>>>> this out-of-band. It cannot be discovered during negotiation, because > >>>>>> it is assumed the regular UDP ports are blocked, which is the only > >>>>>> reason to attempt TCP to begin with. > >>>>> > >>>>> I read the draft with this assumption in mind (see above), but this > >>>>> should be clarified in the document to address this question from Ben. > >>>> > >>>> Imagine a misconfigured client opening a connection to an web server on > >>>> port 80, expecting to find a VPN service. What happens? I think that a > >>>> consequence of the design approach to allow this to run over ports > >>>> assigned to other protocols is that you need to consider that sort of > >>>> thing. > >>>> > >>>>>> > >>>>>>>> - Appendix A: Doesn't the use of the NULL cipher invalidate one of > >>>>>>>> the > >>>>>>>> primary reasons to use TLS? (Namely to obscure the fact that this is > >>>>>>>> not > >>>>>>>> HTTP, or whatever other protocol is assigned to the port?) > >>>>>>> > >>>>>>> > >>>>>>> Editors/AD correct me if I am wrong, but... > >>>>>>> No, if TLS is used with a NULL cipher, it'll pass inspection of a > >>>>>>> middle box validating the protocol. This doesn't need to use the > >>>>>>> cipher as it's negotiating the IPsec connection. > >>>>>> > >>>>>> > >>>>>> right, TLS happens to use encryption to get out, but it is not the > >>>>>> encryption of the actual IKE/IPsec protocols, which keep using their > >>>>>> own channel negotiations. > >>>>> > >>>>> I think clarifying this further in the draft would be helpful. > >>>> > >>>> I agree, because I’m still confused :-) > >>>> > >>>> To clarify my question: Assuming the case of TLS encapsulation to the > >>>> HTTPS port across a DPI middle-box that hates that sort of thing. If TLS > >>>> uses the NULL cipher, can the middlebox not tell that the protocol over > >>>> TLS is not HTTP? (I will defer to the experts.) > >>> > >>> IPsec WG participants should chime in here, Yoav may know for sure > >>> with his background, I'm sure others too. > >>> > >>> I'd guess that a DPI would not pick it up as the protocol inspection > >>> most likely assumes when it sees TLS, that the traffic is encrypted > >>> and looks no further for inspection/blocking purposes. The > >>> middleboxes that do some protocol inspection aren't like the ones from > >>> 15-20 years ago that dug into the protocol (blocking FTP commands, > >>> etc.). > >>> > >>> The use of TCP 443 for this has been in place for a decade or two, > >>> Google QUIC also uses TCP 443, and I'm sure other services do too. So > >>> tunneling does work. > >>> > >>> For purity, are we worried if this is TLS or HTTP/TLS (as the port > >>> usage specifies) or does that matter? > >>> > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> > >>> Best regards, > >>> Kathleen > >> > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
