Thank you for your response, please find my reply below
-----Original Message-----
From: Fernando Gont [mailto:fg...@si6networks.com]
Sent: Monday, December 17, 2012 5:32 PM
To: Rafiee, Hosnieh
Cc: ipv6@ietf.org; bob.hin...@gmail.com
Subject: Re: FW: 6MAN WG Last Call:
<draft-ietf-6man-stable-privacy-addresses-01.txt>
Hi, Hosnieh,
Thanks so much for your feedback! Please find my comments inline...
On 12/17/2012 12:18 PM, Rafiee, Hosnieh wrote:
> 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
>>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.
> 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.
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.
>* 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.
> 3- the result of these false assumptions is that the possibility of
> attacks is probable is false too.
>Please state what are the "assumptions" you're referring to.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
