On Apr 26, 2017 16:23, "Tommy Pauly" <tpa...@apple.com> wrote:
On Apr 26, 2017, at 1:08 PM, Ben Campbell <b...@nostrum.com> wrote: 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”? Yes, I meant "on a new incoming connection". Sorry! Thanks for clarifying. I thought I was experiencing telechat blindness ;-) Spencer Thanks, Tommy 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
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
