Skip to main content

Last Call Review of draft-ietf-dhc-dhcpv6-vendor-message-
review-ietf-dhc-dhcpv6-vendor-message-secdir-lc-gondrom-2010-02-20-00

Request Review of draft-ietf-dhc-dhcpv6-vendor-message
Requested revision No specific revision (document currently at 01)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-02-16
Requested 2010-02-05
Authors Bernie Volz
Draft last updated 2010-02-20
Completed reviews Secdir Last Call review of -?? by Tobias Gondrom
Assignment Reviewer Tobias Gondrom
State Completed
Review review-ietf-dhc-dhcpv6-vendor-message-secdir-lc-gondrom-2010-02-20
Completed 2010-02-20
review-ietf-dhc-dhcpv6-vendor-message-secdir-lc-gondrom-2010-02-20-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 draft correctly states that the introduction basically allows each
vendor to introduce its own security problems based on the
functionality triggered by the vendor specific messages. The
specification that "Relay agents SHOULD relay these messages ... 
unless the relay agent understands the specific message and knows that
the message was directed at it." can worsen security risks by allowing
quite far reaching/remote attacks as relays will forward any vendor
message which they do not understand. Although this paradigm makes
sense for network operation, this may result in unintended side effects
regarding security and attack vectors.





1. COMMENT on section 3 on page 3: 


-  msg-type             VENDOR-SPECIFIC (TBD)


What do you mean by TBD? (if you mean "to be defined", my opinion is
that this is definitely not appropriate for a Standards Track document)





2. COMMENT on section 4 page 4: 


"Vendors using this new message should use the DHCPv6 security
mechanisms..."


=> maybe a SHOULD would be more appropriate in this case.





3. Minor note: the draft has expired on Feb-2. 





4. COMMENT: 


And last but not least a general personal comment: 


The document describes how to introduce vendor specific messages which
will be solely in the control of the vendor. These message codes and
their underlying functionality are unspecified and totally beyond IANA
or IETF control.


This can introduce basically any set of security and interoperability
problems and I am not sure how this approach will support
interoperability or would benefit the operation of the internet as a
whole. But probably the DHC WG members knows better. Still, considering
this question I wonder why this is in the status of "Standards Track"
and not "Experimental".





Best regards, Tobias








Tobias Gondrom


Sloan Fellowship 2009


London Business School


email: 

tobias.gondrom at gondrom.org


mobile: +447521003005