Subject: FW: 6MAN WG Last Call: <draft-ietf-6man-stable-privacy-addresses-01.txt>

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Mon, 17 Dec 2012 16:18:56 +0100

Follow-up

To clarify my question from my last email, I raise three important issues here:

1 - The assumption made in this draft is not true because, according to RFC 4941, the IID is randomly generated and so will never be the same value (The use of stable storage in the first approach and the use of CGA in the second approach prevent the generation of the same value)

2 - It takes the same cryptographic approach as explained for CGA in RFC 3972 (sec value 0). The main reason for using CGA is because of the generation of a random IID, regardless of ,whether or not, it is used in SEND. Now the real question is what are the differences between this algorithm and those explained in RFC 3972 and RFC 4941?

3- the result of these false assumptions is that the possibility of attacks is probable is false too.

Thank you,
Hosnieh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Montag, 17. Dezember 2012 14:25
To: [email-masked] Mailing List
Cc: Bob Hinden
Subject: 6MAN WG Last Call: <draft-ietf-6man-stable-privacy-addresses-01.txt>

All,

This message starts a three week (to account for the holidays) 6MAN Working Group on advancing:

	Title           : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless
                          Address Autoconfiguration (SLAAC)
	Author(s)       : Fernando Gont
	Filename        : draft-ietf-6man-stable-privacy-addresses-01.txt
	Pages           : 17
	Date            : 2012-10-07

       http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/

as a Proposed Standard.  Substantive comments and statements of support for advancing this document should be directed to the mailing list.  Editorial suggestions can be sent to the author.  This last call will end on 7 January 2013.

The chairs would also like to solicit a few people to do a detailed review of this document.  Please contact the chairs directly.

Regards,

Bob Hinden & Ole Trøan 

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 17 Dec 2012 13:31:36 -0300

Hi, Hosnieh,

Thanks so much for your feedback! Please find my comments inline...

On 12/17/2012 12:18 PM, Rafiee, Hosnieh wrote:
> 1 - The assumption made in this draft is not true because, according

What's the "assumption" you're referring to?

> 2 - It takes the same cryptographic approach as explained for CGA in
> RFC 3972 (sec value 0). The main reason for using CGA is because of
> the generation of a random IID, regardless of ,whether or not, it is
> used in SEND. Now the real question is what are the differences
> between this algorithm and those explained in RFC 3972 and RFC 4941?

RFC4941 generates random addresses that change over time -- they are not
stable within the same network. And they are generated *in addition* to
the traditional SLAAC addresses.

When it comes to CGAs, Some of them include:

* draft-ietf-6man-stable-privacy-addresses is simpler, and has fewer
requirements on the host. e.g., each host can use whatever hash
algorithm they want, since no other host will need to "verify" the address.

* The goal of CGAs is that you do have access to all the input materials
to the hash function and know all of the implementation details, such
that any node can regenerate/verify the IID. The goal of
*stable-privacy-addresses is that you *cannot* generate the IIDs (hence
we rely on a secret key).

* It doesn't make much sense to use CGAs along with Privacy addresses
(RFC4941) -- or else an attacker would always use RFC4941, such that
hosts cannot verify the CGAs. OTOH, *stable-privacy-addresses are
orthogonal to RFC 4941.

> attacks is probable is false too.

Please state what are the "assumptions" you're referring to.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Tue, 18 Dec 2012 00:25:18 +0100

Thank you for your response, please find my reply below

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Monday, December 17, 2012 5:32 PM
To: Rafiee, Hosnieh
Cc: [email-masked]; [email-masked]
Subject: Re: FW: 6MAN WG Last Call: <draft-ietf-6man-stable-privacy-addresses-01.txt>

Hi, Hosnieh,

>>What's the "assumption" you're referring to?
- One of your assumption is that the privacy extension is often disabled in nodes on the network. But this is not true.  By default, the Windows OS uses the privacy extension to generate its IID and, based on the statistics (bad news or good news), Windows is the most popular OS in the world!
For servers you cannot have changeable IP addresses so you must use another approach to solve your problem with DNS. Usually a fixed range of IP addresses are used with servers. But for clients, if they care about privacy, then they use the algorithm explained in section 3.2 of RFC 4941. According to this algorithm, they do not start new connections with old IP addresses. So how can an attacker track them by only using their IP addresses? The attacker can do this only by trying to map the hostname to the IP address of that node. In your approach this attack is still possible otherwise the hostname and IP address are changed at the same time and that is rare!
Moreover, if a node does not change its IID in the same subnet, it will still be vulnerable to privacy related attacks. Now the question is, If you also want to use life time for this IID or IP address, then it becomes exactly the same as RFC privacy extension. 

As explained in the section 2 of your draft
o  The resulting interface identifiers remain constant/stable for
      each prefix used with SLAAC within each subnet.  That is, the
      algorithm generates the same interface identifier when configuring
      an address belonging to the same prefix within the same subnet.
This is the same as  for the privacy extension RFC where the same IID is generated for each prefix for a certain time

Your draft:
We note that of use of the algorithm specified in this document is
   (to a large extent) orthogonal to the use of "Privacy Extensions"
   [RFC4941].  Hosts that do not implement/use "Privacy Extensions"
   would have the benefit that they would not be subject to the host-
   tracking and host scanning issues discussed in the previous section.
   On the other hand, in the case of hosts employing "Privacy
   Extensions", the method specified in this document would prevent host
   scanning attacks and correlation of node activities across networks
   (see Appendix A).
If a host wants to implement something, it can also implement privacy extensions. Concerning host scanning attacks, if the attacker is inside a network that uses stateless autoconfiguration, then it is not feasible for him to do host scanning. Generally, for IPv6, a host scanning attack is not a good method because of the IPv6 large address space. What an attacker might do is find the host IP addresses and just listen to the messages (NDP or DHCPv6) exchanged between hosts on that network and . if it is an outside attacker, then attacking DNS and finding all the necessary information is easier than doing host scanning. Thus this is not one of the desired types of attack for use in IPv6 networks.

>RFC4941 generates random addresses that change over time -- they are not stable within the same network and they are generated *in addition* to the traditional SLAAC addresses.

>* draft-ietf-6man-stable-privacy-addresses is simpler, and has fewer requirements on the host. e.g., each host can use whatever hash algorithm they want, since no other host will need to "verify" the address.
When using CGA a host can use another algorithm, but as you also mentioned, the other host would have to support that algorithm. 

>* The goal of CGAs is that you do have access to all the input materials to the hash function and know all of the implementation details, such that any node can regenerate/verify the IID. The goal of >*stable-privacy-addresses is that you *cannot* generate the IIDs (hence we rely on a secret key).
In the privacy extension the use of CGA is also mentioned as a way of generating a random IID. However, that RFC does not explain CGA in detail as to how to use that algorithm. It appears to be missing from that RFC. So, my suggestion is, as you used almost the same algorithm for the  CGA generation as for the  IID (except using one different input for hashing and omit the condition like if in CGA use the sec value equal to 0), then you could explain your approach the better by  explaining the section that is missing from the privacy extension RFC that I pointed out earlier. 

>(RFC4941) -- or else an attacker would always use RFC4941, such that hosts cannot verify the CGAs. OTOH, *stable-privacy-addresses are orthogonal to RFC 4941.
Why doesn't it make sense? We are not talking about the attacker, we are talking about nodes that want to prevent privacy related attacks as I explained in the prior paragraph. So, when you use a sec value of 0 (you do not care a lot about security), then you will get a fast randomly generated address.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 17 Dec 2012 23:01:03 -0300

Hi, Hosnieh,

On 12/17/2012 08:25 PM, Rafiee, Hosnieh wrote:
> - One of your assumption is that the privacy extension is often
> disabled in nodes on the network. But this is not true. 

The document never makes such assumption. Actually, whether that happens
or not is kind of irrelevant for this document.

What the document does mention regarding RFC4941 is:

* *stable-privacy-addresses are orthogonal to RFC4941
* stable-privacy-addresses are valuable even if you implement RFC4941
* If you disable RFC4941, stable-privacy-addresses brings most of the
benefits of RFC4941.

That said, many deployments result in RFC4941-addresses being turned off
(e.g., see the slideware of many of Ron Broesma's presentations). It's
not that they are turned off by default, but rather that they are
manually turned off.

> By default,
> the Windows OS uses the privacy extension to generate its IID and,
> based on the statistics (bad news or good news), Windows is the most
> popular OS in the world! 

As noted above, many deployments turn off privacy addresses.

> DNS. Usually a fixed range of IP addresses are used with servers. But
> for clients, if they care about privacy, then they use the algorithm
> explained in section 3.2 of RFC 4941. According to this algorithm,
> they do not start new connections with old IP addresses. So how can
> an attacker track them by only using their IP addresses?

RFC4941-addresses are generated *in addition* to the traditional SLAAC
addresses. And as long as such addresses are there, you can be tracked
(please see the whole Appendinx in
draft-ietf-6man-stable-privacy-addresses).

> rare! Moreover, if a node does not change its IID in the same subnet,
> it will still be vulnerable to privacy related attacks.

The only attack he will be vulnerable to is an attacker correlating
different connections from the same node (which is, IMO, less of an
issue when compared with a node being tracked across networks).

That said, please check:

* Escudero, A. 2002. PRIVACY EXTENSIONS FOR STATELESS ADDRESS
AUTOCONFIGURATION IN IPV6 - ‘REQUIREMENTS FOR UNOBSERVABILITY.
RVK02, Stockholm. Available at:
<http://web.it.kth.se/~aep/PhD/docs/paper3-rvk2002.pdf>

* Dupont, F., Savola, P. 2004. RFC 3041 Considered Harmful. IETF
Internet-Draft (draft-dupont-ipv6-rfc3041harmful-05.txt), work in progress.

> Now the
> question is, If you also want to use life time for this IID or IP
> address, then it becomes exactly the same as RFC privacy extension.

Nobody even suggested that. For instance, if these addresses had a
lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the
first place.

> As explained in the section 2 of your draft o  The resulting
> interface identifiers remain constant/stable for each prefix used
> with SLAAC within each subnet.  That is, the algorithm generates the
> same interface identifier when configuring an address belonging to
> the same prefix within the same subnet. This is the same as  for the
> privacy extension RFC where the same IID is generated for each prefix
> for a certain time

With RFC4941, you don't get the same IID when you return to the same
subnet. i.e., RFC4941-addresses are not stable within the same subnet.

> Your draft: We note that of use of the algorithm specified in this
> document is (to a large extent) orthogonal to the use of "Privacy
> Extensions" [RFC4941].  Hosts that do not implement/use "Privacy
> Extensions" would have the benefit that they would not be subject to
> the host- tracking and host scanning issues discussed in the previous
> section. On the other hand, in the case of hosts employing "Privacy 
> Extensions", the method specified in this document would prevent
> host scanning attacks and correlation of node activities across
> networks (see Appendix A). If a host wants to implement something, it
> can also implement privacy extensions. 

In some network deployments, RFC4941 addresses are deemed as undesirable.

> Concerning host scanning
> attacks, if the attacker is inside a network that uses stateless
> autoconfiguration, then it is not feasible for him to do host
> scanning. Generally, for IPv6, a host scanning attack is not a good
> method because of the IPv6 large address space. 

This is simply not true. Please check:
<http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning>

> What an attacker
> might do is find the host IP addresses and just listen to the
> messages (NDP or DHCPv6) exchanged between hosts on that network and
> . if it is an outside attacker, then attacking DNS and finding all
> the necessary information is easier than doing host scanning. Thus
> this is not one of the desired types of attack for use in IPv6
> networks.

This whole topic is discussed in
<http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning>

>> * draft-ietf-6man-stable-privacy-addresses is simpler, and has
>> fewer requirements on the host. e.g., each host can use whatever
>> hash algorithm they want, since no other host will need to "verify"
>> the address.
> When using CGA a host can use another algorithm, but as you also
> mentioned, the other host would have to support that algorithm.

And you need to tell which algorithm is in use -- in other words, the
whole thing needs to be specific at the "bit level". This is not the
case for *stable-privacy-addresses.

>> * The goal of CGAs is that you do have access to all the input
>> materials to the hash function and know all of the implementation
>> details, such that any node can regenerate/verify the IID. The goal
>> of >*stable-privacy-addresses is that you *cannot* generate the
>> IIDs (hence we rely on a secret key).
> In the privacy extension the use of CGA is also mentioned as a way of
> generating a random IID. However, that RFC does not explain CGA in
> detail as to how to use that algorithm. It appears to be missing from
> that RFC. So, my suggestion is, as you used almost the same algorithm
> for the  CGA generation as for the  IID (except using one different
> input for hashing and omit the condition like if in CGA use the sec
> value equal to 0), then you could explain your approach the better by
> explaining the section that is missing from the privacy extension RFC
> that I pointed out earlier.

Please take a look at the CGA spec. It includes too many things that are
needed for CGAs to be verified. -- Nothing of that is needed for the
purpose of *stable-privacy-addresses. In stable-privacy we require a
secret (CGAs don't), we also include the possible network ID, etc.

So yeah, both approaches use hashes... bot lots of things use hashes...

>> * It doesn't make much sense to use CGAs along with Privacy
>> addresses (RFC4941) -- or else an attacker would always use
>> RFC4941, such that hosts cannot verify the CGAs. OTOH,
>> *stable-privacy-addresses are orthogonal to RFC 4941.
> Why doesn't it make sense? We are not talking about the attacker, we
> are talking about nodes that want to prevent privacy related attacks
> as I explained in the prior paragraph. So, when you use a sec value
> of 0 (you do not care a lot about security), then you will get a fast
> randomly generated address.

This would be a use of CGAs that is completely different from the goals
specified in RFC 3972. And there are lots and lots of details that are
different:

* In 3972, there's no secret. Hence, the attacker might be able to
compute the IID himself (assuming the algorithm and the input parameters
are known).

* If the CGA Modifier changes (as they are suposed to), then the
addresses are not contant within the same network (each time you
generate a CGA, the IID would be different).

    [yes, one could change the spec and now argue tha the
     "Modifier" is now the secret key, but....]

* The remove 3 bits from the number of bits we can randomize.

... and the list could continue.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Dec 2012 08:06:15 +0000

On 18/12/2012 02:01, Fernando Gont wrote:
...
> lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the

I suggest that you add a discussion of site renumbering considerations.
The problems described in draft-ietf-6renum-static-problem need
to be avoided.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Dec 2012 10:41:50 -0300

Hi, Brian,

> The problems described in draft-ietf-6renum-static-problem need

Could you please elaborate what you have in mind? (i.e., how you think
this should be addressed, without rehashing the whole discussion in the
aforementioned I-D -- I guess one or two paragraphs, and a reference to
draft-ietf-6renum-static-problem?)

Thanks!

Best regards,

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Dec 2012 14:55:53 +0100

> draft-ietf-6renum-static-problem?)

my understanding was that addresses based on these interface-ids would have the same address lifetime properties as RFC4861 addresses.
is it the draft's reference to "static addresses" that creates the confusion?

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Dec 2012 11:13:41 -0300

> my understanding was that addresses based on these interface-ids would have the same address lifetime properties as RFC4861 addresses.

Agreed. What I meant in my response to Hosnieh is that these addresses
behave (in terms of lifetimes) in the same way as traditional slaac
addresses, but do not vary over time as  RFC4941-addresses.

So it's not clear to me what's the concern here.

> is it the draft's reference to "static addresses" that creates the confusion?

I had the impression that Brian suggested to include something along the
lines of "while having table addresses is nice, beware that you should
probably not rely strongly on them being stable, since a renumbering
event could make them change" (e.g., DNS is always valuable to contact
servers, even if the addresses are stable, etc.). Maybe he can
elaborate.... :-)

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Dec 2012 14:35:54 +0000

> So it's not clear to me what's the concern here.

The concern is that we are still mainly ignoring the renumbering
problem, and in some years time this will be serious for users.
But if you add "From the point of view of renumbering, these addresses
behave like RFC4941 addresses" the point is covered.

> servers, even if the addresses are stable, etc.). Maybe he can

I think the above is enough.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Dec 2012 15:40:20 +0100

> behave like RFC4941 addresses" the point is covered.

... behave like RFC4862 addresses.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Dec 2012 14:43:08 +0000

> ... behave like RFC4862 addresses.

Yes, sorry, didn't put my brain on straight today.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Dec 2012 11:53:32 -0300

> behave like RFC4941 addresses" the point is covered.

I think this should be RFC4862 rather than RFC4941. SO, how about this
text in the intro to address the point you've raised:

"Form the point of view of renumbering, these addresses behave as the
traditional addresses resulting from SLAAC [rfc4862]"

?

Thanks!

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Dec 2012 16:51:26 +0000

Yes, thanks.

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Dec 2012 16:21:07 +0000

> The problems described in draft-ietf-6renum-static-problem need

I just realised what was bothering me about Fernando's statement.
It's the stable-privacy IID that has no specified lifetime. Any IP address
formed via SLAAC has the lifetime determined by SLAAC.

I'd still like to see a discussion of renumbering, if the prefix itself
is withdrawn while the host is connected.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Dec 2012 22:19:19 -0300

Hi, Brian,

On 12/25/2012 01:21 PM, Brian E Carpenter wrote:
> It's the stable-privacy IID that has no specified lifetime.

The SLAAC lifetime applies. -- We're just generating IIDs in a diferent
way, but *not* changing SLAAC itself (that's where the lifetimes come from).

> Any IP address

Exactly.

> is withdrawn while the host is connected.

Whatever happens to traditional slaac addresses would happen to
stable-privacy-addresses.

Cheers,