Dear Ray,
Thank you again.
>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.
A further enhancement might be to add a MAC address to the signature. But if the
attack is in layer 2 rather than IP layer, I believe that this attack will also
occur using CGA because the purpose is the same as what we proposed here, but
with longer processing time. As you said, there is a need for monitoring the
system for snooping NDP.
By the way, about 10 minutes for timestamp which was a topic of discussion in
our last email. The replay attack is still not possible because of the other
steps present in the verification process. An example of such a step is the
checking of the public key with his own public key.
Thank you,
Hosnieh
On January 7, 2013 at 6:39 AM Ray Hunter <[email protected]> wrote:
> 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
--------------------------------------------------------------------
