> 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. 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
