Dear Jeremy, Thank you so much for your review and your question. >In reading your ID, I didn't see a mechanism for ensuring a central certification authority like in PKI (eg a CA) like used in SeND/CGA. How can hosts trust the signed NDP messages? Or is this ID >meant to be another option to CGA not necessarily a replacement for SeND?
This mechanism will be used as a replacement for CGA because it is faster, but not for SEND. Usually, for a client, it is enough to just validate address ownership. As you know, like CGA, this mechanism will validate address ownership, but uses fewer steps to accomplish this. This means that a node cannot steal another nodes' IP address because address ownership would need to be proven by verifying the signature and also because a part of his address is his public key. But for nodes, it is important to ensure that a node claiming to be a router is really a router and not an attacker (preventing all nodes from claiming to be a router). In this case, as I explained in the security consideration section of the draft, other RFCs explaining how to use certificates and trusted authorities may be used. An example would be RFC 6494. Thank you, Hosnieh -----Original Message----- From: Duncan, Richard (Jeremy) [mailto:[email protected]] Sent: Sunday, January 06, 2013 5:30 PM To: Hosnieh Rafiee Cc: 'Fernando Gont'; [email protected] Subject: RE: Call for comments on draft-rafiee-6man-ssas-00.txt Dr. Rafiee- In reading your ID, I didn't see a mechanism for ensuring a central certification authority like in PKI (eg a CA) like used in SeND/CGA. How can hosts trust the signed NDP messages? Or is this ID meant to be another option to CGA not necessarily a replacement for SeND? 010100110110010101101101011100000110010101110010001000000100011001101001 Jeremy Duncan Senior Director, IPv6 Network Architect Salient Federal Solutions, Inc. (Now including SGIS & Command Information Inc.) 4000 Legato Road, Suite 600 Fairfax, VA 22033 Google Voice: 540.440.1193 [email protected] Hosnieh Rafiee <[email protected]> wrote: Thanks for your comments. -----Original Message----- From: Fernando Gont [mailto:[email protected]] Sent: Saturday, January 05, 2013 11:32 PM To: Hosnieh Rafiee Cc: [email protected] Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt Hosnieh, I've reviewed the I-D till Section 3 (didn't get into 3.1)... but it looks like the I-D got some things wrong.... Please see in-line... > Abstract > > The default method for IPv6 address generation uses two unique > manufacturer IDs that are assigned by the IEEE Standards Association > [1] (section 2.5.1 RFC-4291) [RFC4291]. What are the two IDs assigned by the IEEE? > This means that a node will > always have the same Interface ID (IID) whenever it connects to a new > network. Because the node's IP address does not change, the node is > vulnerable to privacy related attacks. The IP address does change. It's only the IID part that usually doesn't. > To address this issue, there > are currently two mechanisms in use to randomize the IID, > Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy > Extension [RFC4941]. This is incorrect. CGAs are meant to solve a different problem. Privacy Addresses do (partially) mitigate this issue. > The problem with the former approach is the > computational cost involved for the IID generation. No. The problem with CGAs are: * IPRs * Requirement for a PKI with SEND (which is where CGAs are used) * Small ROI (complexity to implement, complexity to deploy, small number of implementations)... all to solve a problem we have lived with in the IPv4 world for years... and unless you solve other problems (e.g., unsecured DNS), it doesn't make much sense to bother with SEND. > The problem with > the latter approach is that it lacks security. This document offers a > new algorithm for use in the generation of the IID while, at the same > time, securing the node against some types of attack, such as IP > spoofing. These attacks are prevented with the addition of a > signature to the Neighbor Discovery messages (NDP). If you just sign the NDP messages, you're not mitigating spoofing -- how would a non-local host authenticate the packet, if the signatures are in NDP messages (which are only local)? > 1. Introduction > > IPv6 addresses consist of two parts; the subnet prefix, which is > the Global routing prefix, subnet ID, Interface ID (in the case of GUAs, of course) > which is the 64 rightmost bits of IPv6 address. The IEEE Standards > Association [1] (section 2.5.1 RFC-4291) [RFC4291] offered a standard > for the generation of the IPv6 Interface IDs (IID). The IEEE does not standardize IPv6. > They are > generated by the concatenation of an Extended Unique Identifier > (EUI-64) with an Organizationally Unique Identifier (OUI), EUI-64 includes the OUI. > both of > which are assigned by the IEEE Registration Authority (IEEE RA). For > example, if a manufacturer's OUI-36 hexadecimal value is > 00-5A-D1-02-3, and the manufacture hexadecimal value for the > extension identifier for a given component is 4-42-61-71, The latter is assigned by the vendor, not by the IEEE. > EUI-64 value generated from these two numbers will be > 00-5A-D1-02-34-42-61-71. There are two mechanisms used to randomize > the IID; CGA [RFC3972] and Privacy Extension [RFC4941]. Please clarify what you mean by "randomize". > 3. Problem Statement > > The drawback to the IEEE Standards Association approach for the > generation of the IID is one of privacy. That's an *IETF* approach, not IEEE's. > The main problem with the privacy extension mechanism, when using the > first approach, as explained in section 3.2.1 RFC-4941 [RFC4941] , > i.e., using stable storage, is the lack of a provision for use of a > security mechanism. Not sure what you mean by "lack of a provision for use of a security mechanism.". > A Privacy extension can prevent attacks related > to privacy issues, We have already gone through this one: Privacy addresses only *partially* mitigate host-tracking attacks. Thanks, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
