Subject: Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-02.txt

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Jan 2013 06:16:05 -0300

Bob & Ole,

Ping?

Thanks,
Fernando

On 12/29/2012 10:18 PM, Fernando Gont wrote:
> Folks,
> 
> I've rev'ed the document according to our recent email exchange.
> 
> Should we ship the document now?
> 
> Thanks, and have a Happy New Year!
> 
> Best regards,
> Fernando
> 
> 
> 
> 
> On 12/29/2012 10:15 PM, [email-masked] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>  This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
>>
>> 	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-02.txt
>> 	Pages           : 18
>> 	Date            : 2012-12-29
>>
>> Abstract:
>>    This document specifies a method for generating IPv6 Interface
>>    Identifiers to be used with IPv6 Stateless Address Autoconfiguration
>>    (SLAAC), such that addresses configured using this method are stable
>>    within each subnet, but the Interface Identifier changes when hosts
>>    move from one network to another.  The aforementioned method is meant
>>    to be an alternative to generating Interface Identifiers based on
>>    IEEE identifiers, such that the benefits of stable addresses can be
>>    achieved without sacrificing the privacy of users.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-02
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> 

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Jan 2013 15:11:22 -0300

Folks,

Is the I-D ready to ship?

It has been weeks since I posted the last rev. My understanding is that
this I-D is ready to ship (after the clarifications I made on-list, and
the tweaks I made to the I-D). But if there's any remaining bit, I'd
like to know. But if the RTTs for these exchanges get so long, it's
becomes even harder to follow the discussions.

I'm aware that there are folks working on implementations of this I-D,
and it'd be great to progress this I-D sooner than later.

Thanks!

Best regards,
Fernando

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

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sun, 20 Jan 2013 00:49:58 +0200

Hi Fernando,

I would like to make some last comments about your draft, which i
fully support.

First of all, i would like to see a reference to cases where the
prefix doesn't change too often (since this is recommended by many
people for various deployments, i.e. residential dsl) due to
mostly renumbering issues. In this case, Privacy Extensions seem
to offer an advantage in terms of host tracking.

Also, it would be good to include some examples of IIDs produced
by an implementation of the proposed algorithm, taking into
account various scenarios with common parameters.

Lastly, in a comment i had made back in March 2012 regarding your
draft and source address selection, and now looking at current
rfc6724 i can see the following:

Rule 7: Prefer temporary addresses.
If SA is a temporary address and SB is a public address, then prefer
SA. Similarly, if SB is a temporary address and SA is a public
address, then prefer SB.

Although the implementations must provide a mechanism allowing an
application to reverse this, if the above is the default behavior
meaning that if privacy extensions are enabled, temporary
addresses will have preference over your stable addresses, then i
think the following 2 paragraphs don't apply anymore in your
draft. Please correct me if i'm wrong.

On the other hand, in scenarios in which "Privacy
Extensions" are employed, implementation of the mechanism described
in this document would mitigate host-scanning attacks and also
mitigate correlation of host activities.

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

...and some editorial comments...

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.

within the same subnet. => within the same subnet (assuming
parameters defined in Section 3 remain the same).

2. The Interface Identifier is finally obtained by taking the
leftmost 64 bits of the RID value computed in the previous step,
and and setting bit 6 (the leftmost bit is numbered 0) to zero.

and and => and

The resulting Interface
Identifier should be compared against a list of reserved
interface identifiers and to those already employed in an address
of the same network interface and the same network prefix. In
the event that an unacceptable identifier has been generated,
this situation should be handled in the same way as the case of
duplicate addresses

employed in an address of the same network interface and the same
network prefix = > employed in an address of another host
through the same local network interface and using the same
network prefix

In the event that an unacceptable identifier has been generated
=> In the event that such an identifier has been generated

Also if "a list of reserved identifiers" refers to
http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml,
then it should probably be "the list of...".

Unless, we assume everyone is allowed to use its own list of
reserved identifiers.

In the event that a DAD conflict cannot be solved (possibly after
trying a number of different addresses), address configuration would
fail. In those scenarios, nodes MUST NOT automatically fall back to
employing other algorithms for generating interface identifiers.

Shouldn't an error message be logged somewhere?

This document does not require the use of any specific PRF for the
function F() above, since the choice of such PRF is usually a trade-
off between a number of properties (processing requirements, ease of
implementation, possible intellectual property rights, etc.), and
since the best possible choice for F() might be different for
different types of devices (e.g. embedded systems vs. regular
servers) and might possibly change over time.

and might possibly change over time => it might possibly change
over time

since it would mitigate host-
tracking vectors still present when privacy addresses are used
(Appendix A,

(Appendix A, => (Appendix A),

--
Tassos

Fernando Gont wrote on 17/1/2013 20:11:

Folks,

Thanks!

Best regards,
Fernando

Bob & Ole,

Ping?

Thanks,
Fernando

Folks,

Best regards,
Fernando

Abstract:

---

From: Fernando Gont <[email-masked]>
Date: Sat, 19 Jan 2013 22:00:41 -0300

Hi, Tassos,

On 01/19/2013 07:49 PM, Tassos Chatzithomaoglou wrote:
> 
> First of all, i would like to see a reference to cases where the prefix
> doesn't change too often (since this is recommended by many people for
> various deployments, i.e. residential dsl) due to mostly renumbering
> issues. In this case, Privacy Extensions seem to offer an advantage in
> terms of host tracking.

This document notes that for the most part, stable-privacy-addresses are
orthogonal to temporary addresses.

That aside, the main issue with host tracking is when a host moves from
one network to another. If you talk about correlation of host activities
within the same network, then the benefits may be debatable. e.g., if
you have a single host behind a router, then the use of privacy
addresses makes no differences.

> Also, it would be good to include some examples of IIDs produced by an
> implementation of the proposed algorithm, taking into account various
> scenarios with common parameters.

You mean something like what's in slide 21 of
<http://www.si6networks.com/presentations/brucon2012/fgont-brucon2012-recent-advances-in-ipv6-security.pdf>?

> Lastly, in a comment i had made back in March 2012 regarding your draft
> and source address selection, and now looking at current rfc6724 i can
> see the following:
> 
> meaning that if privacy extensions are enabled, temporary addresses will
> have preference over your stable addresses, then i think the following 2
> paragraphs don't apply anymore in your draft. Please correct me if i'm
> wrong.
> 

They would mitigate host-scanning because they eliminate the remaining
predictable addresses. OTOH, they would mitigate host-tracking, since
they eliminate IIDs that are constant across networks.

>    scanning attacks 

For this one, same as above.

> and correlation of node activities across networks
>    (see Appendix A <http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02#appendix-A>).

This is correct. If anything, the only thing that might still be
possible is correlation of activities of hosts that belong to the same
network. However, as noted above, it is debatable the extent to which
privacy addresses help in this area (please see the corresponding
references in the I-D).

> within the same subnet. => within the same subnet (assuming parameters
> defined in Section 3 remain the same).

Should we really make this explicit? --If you change the network
parameters (prefix and/or network_id), you can probably argue that, from
a "logical" point of view, it's a different network.

>        and and setting bit 6 (the leftmost bit is numbered 0) to zero.

Good grief! - Fixed!

> network prefix = > employed in an address of another host through the
> same local network interface and using the same network prefix

No. This is the job of DAD.

> then it should probably be "the list of...".

Really good point. I will add a reference to this registry. Thanks!

> Unless, we assume everyone is allowed to use its own list of reserved
> identifiers.
> 

I wouldn't oppose to this -- however, this is probably "out of scope",
since DAD failures should also be logged when they happen for addresses
generated  with other algorithms. (i.e., IMHO, this requirement should
be in a DAD specification, rather than here).

> and might possibly change over time => it might possibly change over time

Isn't the subject implicit?

> (Appendix A, => (Appendix A),

Fixed.

Thanks so much!

Best regards,

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sun, 20 Jan 2013 12:15:52 +0200

> addresses makes no differences.
Can you please elaborate more on the last sentence?
I can have 2 (or more) hosts within the same network, each one belonging to a different
person/floor/family/etc. With temporary addresses i cannot (easily) track each one, while
with stable addresses i can.
> <http://www.si6networks.com/presentations/brucon2012/fgont-brucon2012-recent-advances-in-ipv6-security.pdf>?
If i understand correctly, those are EUI-64 IIDs.
I was hoping to include some stable IIDs like the ones generated by the described
algorithm, for various combinations of parameters (prefixes, networks, etc).
> privacy addresses help in this area (please see the corresponding

I see you already describe that in your doc, so i'm ok.

> a "logical" point of view, it's a different network.
What happens if i reboot/power-off-on the host or if i manually change the secret key?

> No. This is the job of DAD.
The way it's written, i seems like you expect to have the same host generate more than one
stable IIDs for the same interface/prefix.
If that's the case, then i don't think DAD will have any effect, unless a multicast
loop-back is in effect. And in that case, DAD doesn't consider this a duplicate address.

> be in a DAD specification, rather than here).
Agree (DAD already logs this).
> Isn't the subject implicit?
Ok.

Thanks,
Tassos

---

From: Fernando Gont <[email-masked]>
Date: Mon, 21 Jan 2013 01:15:56 -0300

Hi, Tassos,

> with stable addresses i can.

Simple example: let's say there are two hosts within a subnet, and that
the lifetime of each temp address is 10 hours. Let's say that Host 1 was
bootstrapped at time=0h, while Host 2 was bootstrapped at time=5hs.

Let's say that at time=5h:
Host 1: 2001:db8::1
Host 2: 2001:db8::5

Let's say that at time 10h, I start seeing the following addresses:
2001:db8::7
2001:db8::5

(i.e., one of the addresses is the same, and there's a new address)

It wouldn't be hard to infer that 2001:db8::7  (i.e., Host 1 has changed
its temp address).

> If i understand correctly, those are EUI-64 IIDs.

Note: EUI-64 != MAC address.

draft-ietf6man-stable-privacy-addresses is said to generate Modified
EUI64-format addresses, because it sets the global/local
unicast/multicast bits as appropriate.

> algorithm, for various combinations of parameters (prefixes, networks, etc).

They are going to be random, so... except for the example I referenced
above (in the slideware), I'm not sure how they'd be of help. (the
example from the slideware tries to illustrate that addresses are
constant within a subnet, but *not* across networks).

> What happens if i reboot/power-off-on the host or if i manually change the secret key?

The secret is supposed to be constant. So it should be stored in
non-volatile memory (i.e., nothing special would happen across reboots).

OTOH, if you manually change the secret, of course the corresponding
addresses would change. For instance, that's why two hosts (employing
the same OS) would generate different addresses: because they will
employ different secrets.

> stable IIDs for the same interface/prefix.

No. I just consider the case that the host might be using e.g. temporary
addresses.

Simply put, the aforementioned text is meant to catch cases in which the
algorithm generated an IID that is already in use, or that is reserved.

However, the case of *addresses* that are duplicate is handled by DAD --
since that's part of SLAAC itself.

Thanks so much!

Best regards,