Last Call Review of draft-ietf-dhc-container-opt-
review-ietf-dhc-container-opt-secdir-lc-salowey-2009-04-16-00

Request Review of draft-ietf-dhc-container-opt
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-04-21
Requested 2009-04-09
Draft last updated 2009-04-16
Completed reviews Secdir Last Call review of -?? by Joseph Salowey
Assignment Reviewer Joseph Salowey
State Completed
Review review-ietf-dhc-container-opt-secdir-lc-salowey-2009-04-16
Review completed: 2009-04-16

Review
review-ietf-dhc-container-opt-secdir-lc-salowey-2009-04-16

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. 

I found no major issues with this document.  

The security considerations section doesn't really discuss who is
trusting whom for what in great detail.  I assume that the RG client and
RG server implicitly trust one another as they are on the same box and
communication between them is outside the scope of the document.   I
also assume that the SP server treats the RG client and RG server as a
single entity and does not care that the options are in control of the
RG client before they reach the RG server.   Most of this seems obvious,
but this might clear things up a bit:

"The RG client and RG server are collocated within the RG and are
treated as the same entity by the SP server.  The communication
mechanism between the RG client and RG server is local to the RG and
assumed to protect the option from unauthorized access in transit.  

A rogue server can use this option to pass invalid information to the RG
client, which would then be passed to the Client hosts by the RG server.
This invalid information could be used to mount a denial of service
attack or a man-in-the-middle attack against some applications.

Authentication of DHCP messages (RFC 3118 [RFC3118] and section 20 of
RFC 3315 [RFC3315]) can be used to ensure that the contents of this
option are not altered in transit between the SP DHCP server and RG
client."  

The other comment I have is that I don't think RFC 3118 isn't
particularly deployable.  I can see it being used between the SP server
and RG client where management relationships are in place, but I'm not
sure it is very realistic to deploy between client hosts and the RG
server.  Do other mechanisms such as L2 protection help here?  

Cheers,

Joe