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

List:       ipsec
Subject:    [IPsec] Warren Kumari's No Objection on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT)
From:       Warren Kumari <warren () kumari ! net>
Date:       2017-04-24 21:49:49
Message-ID: 149307058969.14644.15446383091244476863.idtracker () ietfa ! amsl ! com
[Download RAW message or body]

Warren Kumari 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:
----------------------------------------------------------------------

Please also see  Mahesh Jethanandani's OpsDir review -
https://www.ietf.org
/mail-archive/web/ops-dir/current/msg02602.html

Having run into this issue of middle boxes blocking non-UDP/non-TCP, I
think
that this is valuable. The document also covers a bunch of the standard
operational and management considerations, and things like MTU issues,
performance implications, etc.; thanks for this.

One thing that I'd like to note is that this makes it significantly
harder for
an operator to simply block IPsec, but, well, that's kinda the point I
guess... :-)


I did have a number of minor questions and comments:
(bikeshedding) Section 1, Bullet 2: "and ESP packets are sent out over
UDP port
4500" - "sent out over" confused me (especially because ESP UDP is
somewhat unusual
to begin with)  - perhaps "sent using UDP with source and destination
port of 4500"?

Section 1.2: "the role of IKE Initiator and Responder may swap for a
given SA
(as with IKE SA Rekeys)" -- a reference to rekeying would be good -
perhaps
RFC 7296 ?

Section 4: The table containing "IKETCP" should be referenced (e.g:
"containing
the characters "IKETCP" as ASCII values (Figure 3).")

Section 5: "If a Responder is configured to use    TCP encapsulation, it
MUST
listen on the configured port(s) in case    any peers will initiate new
IKE
sessions."  
s/will// (spurious will)

"all of the endpoints equally support TCP encapsulation." -- what does
   equally" mean? All must do it, same TCP port, etc.?

"MOBIKE" needs a reference.

Section 11: "A network device that monitors up to the application layer
will
commonly expect to see HTTP traffic ..." - it might be useful to explain
that
this is simply an example. (the same thing happens if non-SMTP is seen
on
port 25, etc)


_______________________________________________
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]