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 rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-06-15
Requested 2017-06-01
Draft 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
Review review-ietf-tcpm-dctcp-07-secdir-lc-meadows-2017-06-15
Reviewed rev. 07 (document currently at 10)
Review result Has Issues
Review completed: 2017-06-15

Review
review-ietf-tcpm-dctcp-07-secdir-lc-meadows-2017-06-15

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>