Subject: Call for comments on draft-rafiee-6man-ssas-00.txt

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 4 Jan 2013 00:14:34 +0100

Dear All,

This draft addresses the following problem:
Unfortunately the existing drafts do not consider the integration of security and privacy  for the generation of the Interface ID (IID). This draft tries to offer a solution to this problem while at the same time considering the generation and verification times and complexity of the existing algorithms. Please take a look. Comments are greatly appreciated.
Thank you,
Hosnieh

Filename:	 draft-rafiee-6man-ssas
Revision:	 00
Title:		 A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration (SSAS)
Creation date:	 2013-01-02
WG ID:		 Individual Submission
Number of pages: 13
URL:             http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-00.txt
Status:          http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas
Htmlized:        http://tools.ietf.org/html/draft-rafiee-6man-ssas-00

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]. 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. To address this issue, there
   are currently two mechanisms in use to randomize the IID,
   Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy
   Extension [RFC4941]. The problem with the former approach is the
   computational cost involved for the IID generation. 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).

---

From: Ray Hunter <[email-masked]>
Date: Sat, 05 Jan 2013 17:42:04 +0100

I have read this draft.

Following all IMVHO.

The claim in Section 3.1 that replay attacks are avoided by having a
timestamp window of 10 minutes seems rather exaggerated.
10 minutes is an eternity in some computer networks. If I was an
attacker, I would be happy to wait and detect the 10 minute window when
I could cause disruption. That may be enough time to do serious damage
in some systems.

The claim in section 3.2 that DoS attacks are avoided by rate limiting
NDP messages also seems rather exaggerated.
How would a rate filter know in advance which messages to discard
without processing all of the SSAS signatures?
Overloading of the NDP mechanism could still potentially cause nodes to
time out their caches, and/or prevent new peerings from forming.
And including encryption in NDP may actually make it easier to overload
the NDP process rather than harder (because the defender has to do
relatively more work than the attacker in the situation where encryption
is employed compared to if there was no encryption).

The claim in the Security Considerations of /the probability of an
attacker finding the same value is 0.00016, a very small value./ would
seem to be a bit exaggerated. This seems to ignore birthday attacks. And
especially since it appears from the text that the consequence of making
this match is that the information leaked to the attacker directly
relates to 32 bits of the private key. Is that a correct reading? There
are many LANs containing many thousands of nodes, and as an attacker I'd
be happy to passively monitor long term if it meant I could glean
(significant portions of) one public key (that did not rotate very often
and once discovered would potentially be extremely useful). The
recommendation of a /maximum of 2 days/ for public key times ignores the
practical need in many systems for very long lived sessions, and the
difficulty of securely rotating public keys on distributed systems.

In summary, I am currently unconvinced whether this ID as it stands
significantly moves the state of the art forward compared to existing
mechanisms.

regards,
RayH

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 5 Jan 2013 20:45:03 +0100

Dear Ray,

>10 minutes is an eternity in some computer networks. If I was an attacker,
I would be happy to wait and detect the 10 minute window when I could cause
disruption. That may be enough time to do >serious damage in some systems.
I considered the worst case scenario where a network might have a very high
delay rate. I will investigate further to determinate an appropriate time to
use. 

>The claim in section 3.2 that DoS attacks are avoided by rate limiting NDP
messages also seems rather exaggerated.
>How would a rate filter know in advance which messages to discard without
processing all of the SSAS signatures?
Only the source IP address needs to be checked. If the receiver receives
several NA messages in a short period of time (seconds) with this IP
address, then the future messages would be discarded.
An additional option would be to specify the number of messages a node can
receive per minute. This number would be dependent on the CPU power (how
many messages this node can handle per minute so that the other operation of
this node are not affected, because the verification time is usually fixed.)

>The claim in the Security Considerations of /the probability of an attacker
finding the same value is 0.00016, a very small value./ would seem to be a
bit exaggerated. This seems to ignore birthday >attacks. And especially
since it appears from the text that the consequence of making this match is
that the information leaked to the attacker directly relates to 32 bits of
the private key. Is that a >correct reading?
Actually the attacker would need to generate a public key that has 4
sequential bytes (starting from a specific part of the public key (specific
index)) matching those in IP address. It is not feasible or very likely that
an attacker would try to find the private key for this node because, in this
case, he would need to do a brute force attack against the 1024-bit key in
order to find the matching number  to that private key. This option is not
really viable because this public key is just valid for a certain period of
time and will then change. The birthday attack would also be difficult
because, again, the attacker would need to generate a public key and not
just 32 sequential bits. What he generated would have to match the bits
starting from its specific index in order to match the 32 bits of the IP
address. 
To summarize, the attacker would need to generate a 1024 bit public key
where the 32 sequential bits start at a specific point in order to match the
IP address. The mathematical proof that I used depicts the very worst case
scenario where we are just matching 32 against 32. What also needs to be
considered is what the probability is of a public key matching a private key
while at the same time matching the specific sequential 32 bits of this
public key while also matching the 32 last most bits of IP address.

> There are many LANs containing many thousands of nodes, and as an attacker
I'd be happy to passively monitor long term if it meant I could glean
(significant portions of) one public key (that did >not rotate very often
and once discovered would potentially be extremely useful).
In order to avoid the use of an index of 1 (not rotate often issue) as the
starting index of public key, I will change that section to this:
If the second byte of a partial ID is greater than the size of the public
key array in bytes, minus 4, then choose that byte and shift its contents 2
bits to the right (the first two bits will be zero) and consider this number
the starting index of the public key array of bytes. This ensures that the
value of that byte will be less than 124.

>The recommendation of a /maximum of 2 days/ for public key times ignores
the practical need in many systems for very long lived sessions, and the
difficulty of securely rotating public keys on >distributed systems.
If we choose 20 days, the probability would be 0.001609325408935546875 and
that is still a small value. The value of two was chosen as an average life
time. I also explained in the draft that it is recommended to generate
public/private keys on the fly. This means that the implementation of the
SSAS algorithm will do a  better job of supporting automatic key generation
without increasing administration tasks.
As stated in other RFCs, the old IP address will  still be valid for the
current session, but will not be valid for the start of new sessions. The
status of this old  IP address should be changed to deprecated. I will add
this to the draft to clarify the lifetime of the IP address.
 
If there is any further questions or concerns, I will be happy to answer
them.

Thank you,
Hosnieh

-----Original Message-----
From: Ray Hunter [mailto:[email-masked]] 
Sent: Saturday, January 05, 2013 5:42 PM
To: Hosnieh Rafiee
Cc: [email-masked]
Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt

I have read this draft.

Following all IMVHO.

The claim in Section 3.1 that replay attacks are avoided by having a
timestamp window of 10 minutes seems rather exaggerated.
10 minutes is an eternity in some computer networks. If I was an attacker, I
would be happy to wait and detect the 10 minute window when I could cause
disruption. That may be enough time to do serious damage in some systems.

The claim in section 3.2 that DoS attacks are avoided by rate limiting NDP
messages also seems rather exaggerated.
How would a rate filter know in advance which messages to discard without
processing all of the SSAS signatures?
Overloading of the NDP mechanism could still potentially cause nodes to time
out their caches, and/or prevent new peerings from forming.
And including encryption in NDP may actually make it easier to overload the
NDP process rather than harder (because the defender has to do relatively
more work than the attacker in the situation where encryption is employed
compared to if there was no encryption).

The claim in the Security Considerations of /the probability of an attacker
finding the same value is 0.00016, a very small value./ would seem to be a
bit exaggerated. This seems to ignore birthday attacks. And especially since
it appears from the text that the consequence of making this match is that
the information leaked to the attacker directly relates to 32 bits of the
private key. Is that a correct reading? There are many LANs containing many
thousands of nodes, and as an attacker I'd be happy to passively monitor
long term if it meant I could glean (significant portions of) one public key
(that did not rotate very often and once discovered would potentially be
extremely useful). The recommendation of a /maximum of 2 days/ for public
key times ignores the practical need in many systems for very long lived
sessions, and the difficulty of securely rotating public keys on distributed
systems.

regards,
RayH

Hosnieh Rafiee wrote:
> Unfortunately the existing drafts do not consider the integration of
security and privacy  for the generation of the Interface ID (IID). This
draft tries to offer a solution to this problem while at the same time
considering the generation and verification times and complexity of the
existing algorithms. Please take a look. Comments are greatly appreciated.
> URL:
http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-00.txt

---

From: Fernando Gont <[email-masked]>
Date: Sat, 05 Jan 2013 19:31:48 -0300

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
>    [1] (section 2.5.1 RFC-4291) [RFC4291].

What are the two IDs assigned by the IEEE?

>    This means that a node will 
>    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 
>    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 

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-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 5 Jan 2013 23:44:13 +0100

Thanks for your comments. 

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Saturday, January 05, 2013 11:32 PM
To: Hosnieh Rafiee
Cc: [email-masked]
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...

* IPRs

* 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.

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)?

EUI-64 includes the OUI.

Thanks,

---

From: "Duncan, Richard (Jeremy)" <[email-masked]>
Date: Sun, 6 Jan 2013 16:30:01 +0000

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-masked]

Hosnieh Rafiee <[email-masked]> wrote:

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]]
Sent: Saturday, January 05, 2013 11:32 PM
To: Hosnieh Rafiee
Cc: [email-masked]
Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt

Hosnieh,

Please see in-line...

* IPRs

EUI-64 includes the OUI.

Thanks,

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 6 Jan 2013 18:02:19 +0100

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-masked]] 
Sent: Sunday, January 06, 2013 5:30 PM
To: Hosnieh Rafiee
Cc: 'Fernando Gont'; [email-masked]
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?

Jeremy Duncan
Salient Federal Solutions, Inc. (Now including SGIS & Command Information
Inc.)

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]]
Sent: Saturday, January 05, 2013 11:32 PM
To: Hosnieh Rafiee
Cc: [email-masked]
Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt

Hosnieh,

Please see in-line...

* IPRs

EUI-64 includes the OUI.

Thanks,

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 6 Jan 2013 21:39:26 +0100

Dear Ahmad,

Thank you so much for your comments. 

>SEND already offers what you are looking for. It has the Timestamp and the
Signature options which are attached to the DNP messages.

As I explained in my last email to Jeremy, It just updates SEND and does not
replace it. It updates SEND because of the signature contents. I also
explained in the draft that we used the same timestamp as is used in SEND.

>I agree with the claim that CGA is compute intensive, but one can use Sec=0
or 1. In this case the computation of the CGA (SEND) would be equivalent to
the complexity of your approach.  
I compared it with both sec value 0 and sec value 1. I did not consider sec
value higher because it is not really feasible in practice that someone wait
for 2 or 3 hours to days to generate an address. CGA for 1 it is 600 times
more. For zero it is about 10 to 20 times more. 

The computation of this algorithm is faster than that for CGA and also the
verification process is much faster. In the verification process you do not
need to do all the CGA generation processing in reverse in order to verify
it. With CGA you also have to include the verification time for the
signature even though we say we use a sec value of 0 this is not considered
in the verification process. For CGA you also need to include an extra 17
bytes of options (modifier and collision count) in the packet, but with SSAS
the packet size would be less. 

Thank you,
Hosnieh

-----Original Message-----
From: Al-Sadeh, Ahmad [mailto:[email-masked]] 
Sent: Sunday, January 06, 2013 9:10 PM
To: Hosnieh Rafiee; [email-masked]
Cc: [email-masked]
Subject: RE: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt

Hosnieh,
I have read your draft. And I have the following comments.
SEND already offers what you are looking for. It has the Timestamp and the
Signature options which are attached to the DNP messages. So, the new
benefits of your approach are not clear to me.
I agree with the claim that CGA is compute intensive, but one can use Sec=0
or 1. In this case the computation of the CGA (SEND) would be equivalent to
the complexity of your approach.  Therefore the enhancements that are
proposed to protect the user privacy by setting a lifetime for the generated
address (e.g. 2 days) or generating the key pairs by CGA code can be
directly applied to the CGA and SEND implementation without significant
change to proposed standard.
In Section 5, ". it provides proof of address ownership at a speed that is
about 600 times faster than that of the CGA algorithm."
For which Sec value this comparison was done?
Regards,
Ahmad AlSadeh

________________________________
From: [email-masked] [[email-masked]] On Behalf Of
Hosnieh Rafiee [[email-masked]]
Sent: 04 January 2013 21:13
To: [email-masked]
Subject: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt

Dear All,

Title:           A Simple Secure Addressing Generation Scheme for IPv6
AutoConfiguration (SSAS)

Abstract:

_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Ray Hunter <[email-masked]>
Date: Mon, 07 Jan 2013 12:39:44 +0100

inline.

Hosnieh Rafiee wrote:
> 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

---

From: "Al-Sadeh, Ahmad" <[email-masked]>
Date: Sun, 6 Jan 2013 21:09:53 +0100

Hosnieh,
I have read your draft. And I have the following comments.
SEND already offers what you are looking for. It has the Timestamp and the Signature options which are attached to the DNP messages. So, the new benefits of your approach are not clear to me.
I agree with the claim that CGA is compute intensive, but one can use Sec=0 or 1. In this case the computation of the CGA (SEND) would be equivalent to the complexity of your approach.  Therefore the enhancements that are proposed to protect the user privacy by setting a lifetime for the generated address (e.g. 2 days) or generating the key pairs by CGA code can be directly applied to the CGA and SEND implementation without significant change to proposed standard.
In Section 5, “… it provides proof of address ownership at a speed that is about 600 times faster than that of the CGA algorithm.”
For which Sec value this comparison was done?
Regards,
Ahmad AlSadeh

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hosnieh Rafiee [[email-masked]]
Sent: 04 January 2013 21:13
To: [email-masked]
Subject: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt

Dear All,

Abstract:

---

From: Hosnieh <[email-masked]>
Date: Mon, 7 Jan 2013 11:23:53 -0500 (EST)

Dear Ray,

Thank you again.

>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