inline. Hosnieh Rafiee wrote: > 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. A rather exaggerated claim IHMO. You may have tied a L2 address to an IPv6 address via NDP, but L2 addresses are generally not tightly coupled to nodes. An attacker could let NDP complete normally (including any signatures/authorizations you like) and then target/corrupt/overload the L2 MAC forwarding table so they can insert (unsigned) spoof traffic packets and receive any replies in promiscuous mode. You'd probably need to additionally deploy some form of NDP snooping and first hop security on your L2 switches to prevent that class of attack on wired networks. On wireless networks you don't even have that option.
> 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 --------------------------------------------------------------------
