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 jeremy.dun...@salientfed.com Hosnieh Rafiee <i...@rozanak.com> wrote: Thanks for your comments. -----Original Message----- From: Fernando Gont [mailto:fg...@si6networks.com] Sent: Saturday, January 05, 2013 11:32 PM To: Hosnieh Rafiee Cc: ipv6@ietf.org 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: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
