[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    [IPsec] Ben Campbell's No Objection on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT)
From:       Ben Campbell <ben () nostrum ! com>
Date:       2017-04-26 18:37:58
Message-ID: 149323187843.2881.11864791218189918574.idtracker () ietfa ! amsl ! com
[Download RAW message or body]

Ben Campbell has entered the following ballot position for
draft-ietf-ipsecme-tcp-encaps-09: No Objection

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Update: Thanks for proposing text to address my DISCUSS point. I've
cleared the discuss, with the assumption the proposed edit (or similar)
will make it into the draft.

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.

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

-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?)

Editorial Comments:

- Please expand IKE and ESP on first mention in both the abstract and
body.

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


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]