Skip to main content

Last Call Review of draft-ietf-dna-simple-
review-ietf-dna-simple-secdir-lc-sheffer-2009-11-20-00

Request Review of draft-ietf-dna-simple
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-11-17
Requested 2009-10-22
Authors Suresh Krishnan , Greg Daley
I-D last updated 2009-11-20
Completed reviews Secdir Last Call review of -?? by Yaron Sheffer
Assignment Reviewer Yaron Sheffer
State Completed
Request Last Call review on draft-ietf-dna-simple by Security Area Directorate Assigned
Completed 2009-11-20
review-ietf-dna-simple-secdir-lc-sheffer-2009-11-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.




 




This document provides a simple procedure (for some value of
“simple”) to detect whether an IPv6 node is reconnecting into a
network it’s previously seen.




 




I should prefix these comments by a big disclaimer re: my very
basic IPv6 expertise.




 




Security




 




The Security Considerations are focused on one specific
aspect, namely the use of SEND. I think we should make clear here that none of
the DNA operations by themselves add any measure of security, unless SEND is
actually used. Specifically, I suggest to add the text: “The DNA
procedure does not in itself provide positive, secure authentication of the
router(s) on the network, or authentication of the network itself, as e.g. would
be provided by mutual authentication at the link layer. Therefore when such assurance
is not available, the host MUST NOT make any security-sensitive decisions based
on the DNA procedure. In particular, it MUST NOT decide it has rejoined a network
known to be physically secure, and proceed to abandon cryptographic protection.”




 




Other Comments




 




4.1: DUID - is this the host’s DUID or the router's? Per
RFC 3315, both have such a value.




4.3: "all currently configured IP addresses" - but
only for this physical interface, right?




4.8: why is no DAD performed? Someone else might have joined
the network while I was disconnected, and has a duplicate of my address.