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.