Hi Ben & others, I may be able to help on a few of these, but the editors (etc.), please correct me if necessary.
On Tue, Apr 25, 2017 at 9:42 PM, Ben Campbell <b...@nostrum.com> wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-ipsecme-tcp-encaps-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have one (hopefully easy) point that I think needs to be fixed before > progressing. > > Section 6, paragraph 6 says : "... if the TCP Originator stream is > missing the stream prefix, or message frames are not parsable as IKE or > ESP messages), it MUST close the TCP connection." > > 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. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive Comments: > > -2: > -- 2nd bullet (and elsewhere) > I think this needs a discussion about how those configured ports are > likely to be in the assigned range, and the likely impact. (I recognize > that tunneling over a port assigned to something else is a primary reason > for doing this. I'm not arguing against it; I just think the implications > warrant discussion.) > > -- 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. > > -3, first paragraph: > Are people confident there will never, ever be a need to demux protocols > other than IKE and ESP? If not, this approach may paint people in a > corner in the future. I ask because we made similar choices with > DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue. > See RFC7983 for a discussion. (Note that this would have been a DISCUSS > point, but I think it's reasonably likely that there really won't be > other protocols here. But I want to make sure people have thought about > it.) > > -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. > > -6: First paragraph: It would be helpful to mention behavior on receipt > of a stream without the magic number here. But see the DISCUSS point. > > -8: "... MUST support dynamically enabling and disabling TCP > encapsulation..." seems unreasonably strong, especially since the > requirement to try UDP before TCP is only a SHOULD. Does this contemplate > situations where it might be impossible to use TCP on the after a network > change? > > - 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. > > Editorial Comments: > > - Please expand IKE and ESP on first mention in both the abstract and > body. These are on the list of well known acronyms: https://www.rfc-editor.org/materials/abbrev.expansion.txt > > -3, 2nd paragraph: s/"may be able"/"is able". > > -3.2, " The SPI field in the ESP header MUST NOT be a zero value." > Is this a new requirement for this draft? That is, does ESP otherwise > allow zero value SPIs? If not, please consider dropping the MUST NOT. > > -5.1: "...SHOULD always attempt negotiate IKE over UDP first" > This is stated several times in the draft, more than once with the > SHOULD. It's better to avoid redundant 2119 keywords. > > -6: "... IKE Figure 1 and ESP Figure 2... ": Broken section > cross-references. > > -10, title: Please expand DPD. > > -12: Several previous sections pointed to section 12 for more information > about why one needed to try direct connections or UDP before TCP. But I > don't find any specifics on that in this section. > > - Appendix A: Why is this an appendix? It contains normative text that > seems central to certain use cases. I was surprised to see no discussion > about using TLS in section 11, where it seemed quite relevant. > > -- Best regards, Kathleen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
