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

[Fernando Gont <[e-mail]>]

Hi, Hosnieh,

On 12/17/2012 08:25 PM, Rafiee, Hosnieh wrote:
>> 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
> 
>>> 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. 

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,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492