Skip to main content

Last Call Review of draft-ietf-tcpm-dctcp-07
review-ietf-tcpm-dctcp-07-secdir-lc-meadows-2017-06-15-00

Request Review of draft-ietf-tcpm-dctcp
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-06-15
Requested 2017-06-01
Authors Stephen Bensley , Dave Thaler , Praveen Balasubramanian , Lars Eggert , Glenn Judd
I-D last updated 2017-06-15
Completed reviews Genart Last Call review of -07 by Orit Levin (diff)
Secdir Last Call review of -07 by Catherine Meadows (diff)
Opsdir Last Call review of -07 by Joe Clarke (diff)
Assignment Reviewer Catherine Meadows
State Completed
Request Last Call review on draft-ietf-tcpm-dctcp by Security Area Directorate Assigned
Reviewed revision 07 (document currently at 10)
Result Has issues
Completed 2017-06-15
review-ietf-tcpm-dctcp-07-secdir-lc-meadows-2017-06-15-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Almost Ready.

This draft concerns a variant of TCP  intended
for datacenters:  DCTCP.   Much of this takes advantage of the
fact that datacenters are controlled  environments managed by a single
authority.  The chief new feature is that the Explicit Notification Congestion
Field  gives information about the amount of congestion present,
instead of simply indicating  whether there is congestion or not.

The Security Considerations section notes that DCTCP inherits the
security considerations of RFC3168,  The only change
that has a potential affect on security beyond those already mentioned in
RFC3168 is a statement that ECT markings (used to indicate whether
endpoints explicit congestion notification) markings SHOULD be applied
to control packets.  RFC3168 does not allow this, and RFC5562 does not allow
this for SYN packets because of the possibility it such packets, since they
would live longer, would facilitate SYN flooding attacks. However, it is argued
here that in a controlled environment SYN flooding would not be an issue.

The section ends as follows:

The security concerns addressed
   by both these RFCs might not apply in controlled environments like
   datacenters, and it might not be necessary to account for the
   presence of non-ECN servers.  Since most servers run virtualized in
   datacenters, additional security can be imposed in the physical
   servers to intercept and drop traffic resembling an attack.

I wasn’t sure how to take this.  The first sentence indicates uncertainty, but
the second sentence gives a clear description of how security can be enforced
on the perimeter in datacenters. It also contradicts the statement at the
beginning, that DCTCP inherits the security considerations of RFC3168.  I think
that this needs to be stated more clearly.  Perhaps, at the beginning you could
say something like

DCTCP enhances ECN and thus inherits the security considerations
   discussed in [RFC3168].  However, because most servers  run virtualized in
   datacenters, additional security can be imposed in the physical
   servers to intercept and drop traffic resembling an attack.  This makes it
   less likely that it will be necessary to account for the presence of non-ECN
   servers, thus mitigating the security considerations in RFC3168.

Also, a  nit:  ECT is never defined in the document.

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil <mailto:catherine.meadows@nrl.navy.mil>