Subject: Comments on draft-ietf-6man-stable-privacy-addresses-07

From: Dave Thaler <[email-masked]>
Date: Mon, 20 May 2013 19:56:53 +0000

Disclaimer: haven't read all the prior list discussion so don't know if this duplicates some existing discussion.

I have some fundamental problems with this document as is.

I will concentrate on sections 1, 2, and Appendix B, being the motivation/goals/justification,
as opposed to the technical details.

Let's start with B.1.1, which attempts to motivate a desire to prevent tracking hosts across networks
using their public address(es):
>   Some time later, the same host moves to a completely different
>   network, and employs the same P2P application, probably even with a
>   different username.  The attacker now interacts with the same host
>   again, and hence can learn its newly-configured stable address.
>   Since the Interface Identifier is the same as the one used before,
>   the attacker can infer that it is communicating with the same device
>   as before.

The above text convolutes two orthogonal issues: higher-layer ID (username in this case) and
location.   The higher-layer ID in other apps would be the DNS name, but here the text uses
the username, though even in P2P applications the higher-layer ID used to resolve an application
or piece of content would already be stable, and the question is what you can link it to.
If you have two addresses that simultaneously or over time are associated with the same 
higher-layer ID, then those two addresses can be linked.  Separate is the issue of location.
Once you have a stable higher-layer ID that anyone can resolve as you move around,
changing the address linked to it doesn't provide any additional privacy (unlinkability).

So one problem with the quoted text is that it does not address the problem of
"a different username" not having a different address (when not moving) and hence
the two higher-layer IDs can be linked using a common address.   Whether one moves or not
is a separate issue.

If unlinkability between two location is desired, then it's key that there be no higher-layer ID
in common that can be linked to both addresses.

Furthermore, this notion of unlinkability is that privacy addresses were designed for.
The first paragraph in B.1.1 implies that one would not want to use privacy addresses in
a P2P scenario, and then goes on to talk about why you lose privacy.   That's faulty logic in my view.
Privacy or lack of privacy is an explicit decision the application or administrator can make.
If you opt out of it, you can't complain that you don't have it.

So if the P2P app opted to use public addresses because the app is already using a 
higher-layer ID that can be resolved to the addresses it will use then no privacy is lost that
wasn't already lost by using the higher-layer ID (which was linkable to the addresses).

The same issue occurs with B.1.2 and B.1.3.

I *do* agree with the address scan prevention goal.   This is why Windows has for the last
10 years used random (not MAC-derived) public (not just temporary) addresses using the
algorithm in 4941.   The IETF works on rough consensus and running code.   We have running
code for over a decade now that's widely deployed (it's the default on all Windows machines
from XPSP3 onwards).   I would fully support an RFC that uses random public (stable) addresses.

But I see no justification for having public addresses (linkable from DNS names, etc.) that
vary by network location.   Nor do I see any justification for having link-local addresses
(linkable to MAC addresses via ND) that vary by network location.

I think this comes down to fundamental disagreements on what a public address is.
A public address is one intended to be resolvable from higher-layer IDs such as DNS names.
A privacy address is one either (a) not intended to be resolvable from higher-layer IDs, OR
(b) one resolvable only from a higher-layer ID that is invented for that address and only ever
resolvable to that single address (example: the ipv6-literal.net form of the address.  See
http://ipv6-literal.com/).

The doc says that apps wanting "server-like" functions use public addresses.   The key is in
defining what that means, and I'll fully agree it would make more sense to have more guidance
in this area.   But specifically "server-like" should be "makes the address linkable to a higher-layer
ID whose lifetime or scope is more than just that one address".  In the IAB documents, we try
to clarify this notion of linkability.

Once you agree on that definition, I think this notion of public addresses that vary by location
does not appear to be useful.   Rather than standardizing an ill-motivated notion, I would 
rather see the WG focus on publishing an RFC focusing on the address scanning problem
that solves it in a way that we already have over a decade of operational experience with,
which is long overdue.  In doing so, the same doc could provide additional clarifications on
when to choose public vs privacy addresses.

-Dave

---

From: Fernando Gont <[email-masked]>
Date: Mon, 20 May 2013 22:42:07 -0300

Hi, Dave,

This issue was debated more than a year ago, at the IETF Paris
timeframe. Since then, the wg adopted this document, and we went through
WGLC and IETF LC. So I'm not sure how it helps to raise this point again
and at this point in time.

That said, please let me try to clarify a few things, and respond to
your email.

Traditional SLAAC addresses suffer from two problems:

1) They result in addresses that follow specific patterns, and hence
allow attackers to reduce the search space when performing
address-scanning attacks.

2) They employ constant identifiers, which allow host-tracking.

I'll focus on "2)", since it seems that you agree with "1)" being a
problem that remains to be solved.

RFC 4941 specifies temporary addresses which change over time. Temporary
addresses help with passive host-tracking where e.g. a server keeps a
log of the IPv6 addresses that connected to it and could possibly
correlate node activities based on the IID (if th IID is constant).

However, there's still the issue of active-host tracking, where a node
(server or otherwise) actively probes a node to track it. As long as
nodes employ addresses which embed constant IIDs, such host tracking
attacks are feasible. For instance,
<http://www.iab.org/wp-content/IAB-uploads/2011/07/IPv6-addresses-privacy-review.txt>
notes:

---- cut here ----
For a temporary address to provide protection against tracking and
re-identification, it cannot be mixed together with a public address
for the same device, otherwise the temporary address could be
correlated to the persistent public address. This aspect has sometimes
been overlooked in applications' use of multiple addresses generated
in different ways.
---- cut here ----

and later adds:

---- cut here ----
The address-scanning problem can be mitigated by using
randomly-generated suffixes for all addresses, whether they are
public/persistent or temporary. These addresses can still be used for
tracking, but they remove the OUI-associated vulnerability and make
address scanning for IPv6 addresses no easier than for IPv4 addresses.
Windows uses random suffixes for all addresses, but many other
implementations do not.
---- cut here ----

This should make it evident that the scheme implemented by Windows fixes
the address-scanning problem, but is still flawed when it comes to privacy.

We have even implemented a tool to track nodes that employ constant IIDs
(whether derived from IEEE-identifiers, or the approach implemented by
Windows). The tool is scan6, availble as part of the IS6 toolkit at:
<http://www.si6networks.com/tools/ipv6toolkit>). The man page for the
tool contains examples of how to use the tool for such purpose.

Some additional comments in-line....

On 05/20/2013 04:56 PM, Dave Thaler wrote:
> I will concentrate on sections 1, 2, and Appendix B, being the
> motivation/goals/justification, as opposed to the technical details.
> 
> Let's start with B.1.1, which attempts to motivate a desire to
> prevent tracking hosts across networks using their public
> address(es):

[FWIW, the motivation is in the Intro, rather than the Appendix.
Appendix B simply rovides a clarification regarding issues not fixed
with RFC4941... and not that long ago even included a statemet such as
"this will be removed prior to publication of this document as an RFC"]

>> network, and employs the same P2P application, probably even with
>> a different username.  The attacker now interacts with the same
>> host again, and hence can learn its newly-configured stable
>> address. Since the Interface Identifier is the same as the one used
>> before, the attacker can infer that it is communicating with the
>> same device as before.
> 
> The above text convolutes two orthogonal issues: higher-layer ID
> (username in this case) and location.  The higher-layer ID in other
> apps would be the DNS name, but here the text uses the username,
> though even in P2P applications the higher-layer ID used to resolve
> an application or piece of content would already be stable, and the
> question is what you can link it to.

The point this para is trying to make is that even if the user is
employing a different username in the hopes of hiding its identity, the
constant IID would reveal the identity of the device. (Put another way,
the text regarding the username could even be considered "superflous" in
this case).

> So one problem with the quoted text is that it does not address the
> problem of "a different username" not having a different address
> (when not moving) and hence the two higher-layer IDs can be linked
> using a common address.   Whether one moves or not is a separate
> issue.

As noted in draft-ietf-6man-stable-priacy-addresses, mitigating
correlation of node activities within the same network is, at times,
virtually impossible. And draft-ietf-6man-stable-privacy-addresses does
not aim to tackle such problem.

> If unlinkability between two location is desired, then it's key that
> there be no higher-layer ID in common that can be linked to both
> addresses.

If you have constant IIDs, node activities can be correlated even
without the need of a higher-layer ID.

> Furthermore, this notion of unlinkability is that privacy addresses
> were designed for. The first paragraph in B.1.1 implies that one
> would not want to use privacy addresses in a P2P scenario, and then
> goes on to talk about why you lose privacy. 

No. It actually argues that RFC 4941 didn't get rid of constant IIDs.
Hence you're still subject of active probing.

Trivial example:

I attend an IETF meeting, and learn the IID of your laptop. Then I can
actively probe your node regarding "Is David at the office?" "Is David
at home?", etc.... simply because your IID is known and constant.

> I *do* agree with the address scan prevention goal.   This is why
> Windows has for the last 10 years used random (not MAC-derived)
> public (not just temporary) addresses using the algorithm in 4941.

Which, as noted above, still brings you IIDs that are constant across
networks -- and the corresponding implications.

> The IETF works on rough consensus and running code.   We have
> running code for over a decade now that's widely deployed (it's the
> default on all Windows machines from XPSP3 onwards).  

A suboptimal (or flawed) scheme implemented in a widely-deployed OS
doesn't change the fact that that the scheme is flawed.

And the wg has been working (and progressing) on this document for more
than a year (which is the "rough consensus" part of your quote above).

> But I see no justification for having public addresses (linkable from
> DNS names, etc.) that vary by network location.   Nor do I see any
> justification for having link-local addresses (linkable to MAC
> addresses via ND) that vary by network location.

Actually, the analysis is: "I see no justification for employing an IID
that is constant across networks, nor do I see why should I embed my
address". That's the philosophy (pro-activity?) one would expect to be
applied. Otherwise you'll likely find out that there's this or that
other mechanism or application which informs e.g. all configured
addresses (e.g. ICMPv6 node information messages, to name one), and you
realize that you should have done the right thing from starters.

> I think this comes down to fundamental disagreements on what a public
> address is. A public address is one intended to be resolvable from
> higher-layer IDs such as DNS names.

I prefer to use terms such as stable vs. non-stable. -- At the end of
the day, nothing prevents you from advertising a temporary address in
the DNS, or *not* advertising a stable one in the DNS.

> The doc says that apps wanting "server-like" functions use public
> addresses.   The key is in defining what that means, 

"receiving incoming connections".

> and I'll fully
> agree it would make more sense to have more guidance in this area.
> But specifically "server-like" should be "makes the address linkable
> to a higher-layer ID whose lifetime or scope is more than just that
> one address".  In the IAB documents, we try to clarify this notion of
> linkability.

I should probably s/server-like/receiving incoming connections/ --
although stable addresses are also useful when you want...er.. the
addresses to be stable (prevent long-lived connections from breaking, etc.).

> Once you agree on that definition, I think this notion of public
> addresses that vary by location does not appear to be useful.

It's the other way around: you should find a very good reason for
embedding a super-cookie in your addresses (whether based on the MAC
address, r a random number). Unless you find one, you shouldn't.

This problem has hit some many protocols so many times that it's kind of
surprising that anyone could argue in favor of constant/predictable IDs
where they are not needed.

Thanks!

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

---

From: Dave Thaler <[email-masked]>
Date: Wed, 22 May 2013 01:34:54 +0000

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> Sent: Monday, May 20, 2013 6:42 PM
> To: Dave Thaler
> Cc: [email-masked]; [email-masked]; Brian Haberman; Ray Hunter;
> Alissa Cooper; tom.petch; Christian Huitema; He Xuan
> Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07
> 
> Hi, Dave,
> 
> This issue was debated more than a year ago, at the IETF Paris timeframe.
> Since then, the wg adopted this document, and we went through WGLC and
> IETF LC. So I'm not sure how it helps to raise this point again and at this point
> in time.

The problem is that the draft does not contain any understandable 
justification, and does not explain the threat model it's trying to address
in a way that's sufficient for readers like me to understand.  So regardless of
whether or not the WG has consensus, the document is lacking in any case.
 
> That said, please let me try to clarify a few things, and respond to your email.
> 
> 1) They result in addresses that follow specific patterns, and hence allow
> attackers to reduce the search space when performing address-scanning
> attacks.

Agreed, that's the part I'm 100% in agreement with addressing.
 
> 2) They employ constant identifiers, which allow host-tracking.

By design.  Host tracking is already allowed with constant higher-layer identifiers,
e.g., DNS names, etc.  So having constant addresses associated with 
constant higher-layer identifiers is not any different.  And having non-constant 
address associated with them does not provide any value add.

> I'll focus on "2)", since it seems that you agree with "1)" being a problem that
> remains to be solved.

Actually it's been solved (and widely deployed) since over a decade ago.  It
remains to be *standardized*, which is the part I agree with.
 
> addresses help with passive host-tracking where e.g. a server keeps a log of
> the IPv6 addresses that connected to it and could possibly correlate node
> activities based on the IID (if th IID is constant).

Right.

> However, there's still the issue of active-host tracking, where a node (server
> or otherwise) actively probes a node to track it. As long as nodes employ
> addresses which embed constant IIDs, such host tracking attacks are feasible.
> For instance, <http://www.iab.org/wp-content/IAB-uploads/2011/07/IPv6-
> addresses-privacy-review.txt>
> notes:
> ---- cut here ----
> For a temporary address to provide protection against tracking and re-
> identification, it cannot be mixed together with a public address for the same
> device, otherwise the temporary address could be correlated to the
> persistent public address. This aspect has sometimes been overlooked in
> applications' use of multiple addresses generated in different ways.
> ---- cut here ----

As you might know, that text is Alissa's nicely edited version of a talk I gave
to the IAB Privacy Program, so I will of course agree with all quotes from it 
and fully endorse their use in any WG document :)   Some of the information
on that page is not currently in any IETF document to my knowledge, but 
ought to be.

> and later adds:
> 
> ---- cut here ----
> The address-scanning problem can be mitigated by using randomly-
> generated suffixes for all addresses, whether they are public/persistent or
> temporary. These addresses can still be used for tracking, but they remove
> the OUI-associated vulnerability and make address scanning for IPv6
> addresses no easier than for IPv4 addresses.

Your conclusion doesn't make sense.   The text is explaining that there are
two issues.  Address scanning is mitigated by random suffixes.  Tracking
is mitigated by using temporary addresses (that change over time and location).
Windows does both, so is not "flawed" as you incorrectly conclude.

> tool contains examples of how to use the tool for such purpose.

The key question is "employ" for what?  For example, if "employ for registering in
DNS" then I assure you I don't need your tool to track that...
If "employ for making outbound TCP connections", then temporary addresses 
(not constant IIDs) are used for that, so again it doesn't apply.
So please elaborate on what you meant.
 
> > Let's start with B.1.1, which attempts to motivate a desire to prevent
> > tracking hosts across networks using their public
> > address(es):
> 
> Appendix B simply rovides a clarification regarding issues not fixed with
> RFC4941... and not that long ago even included a statemet such as "this will
> be removed prior to publication of this document as an RFC"]

I couldn't understand any motivation that made sense to me 
for changing the IID of a *public* address or a *link-local* address, when
moving.
(I of course understand motivation for preventing address scans.)
 
> >> again, and hence can learn its newly-configured stable address. Since
> >> the Interface Identifier is the same as the one used before, the
> >> attacker can infer that it is communicating with the same device as
> >> before.
> >
> > though even in P2P applications the higher-layer ID used to resolve an
> > application or piece of content would already be stable, and the
> The point this para is trying to make is that even if the user is employing a
> different username in the hopes of hiding its identity, the constant IID would
> reveal the identity of the device. (Put another way, the text regarding the
> username could even be considered "superflous" in this case).

Remove superfluous text that confuses the issue.  My point remains about
either there's a higher-layer ID that's constant (in which case changing the
IID is not helpful) or there's not (in which case the app should be using
temporary addresses not stable addresses).   The text provides no clue
as to why an app would opt into stable addresses and then be concerned
about privacy, which makes no sense to me.

> > problem of "a different username" not having a different address (when
> > not moving) and hence the two higher-layer IDs can be linked
> As noted in draft-ietf-6man-stable-priacy-addresses, mitigating correlation of
> node activities within the same network is, at times, virtually impossible. And
> draft-ietf-6man-stable-privacy-addresses does not aim to tackle such
> problem.
> 
> 
> 
> If you have constant IIDs, node activities can be correlated even without the
> need of a higher-layer ID.

Yes, and if you have a higher-layer ID that's constant,  linking it to
non-constant IIDs is not helpful.   So I fail to see the point.

> > were designed for. The first paragraph in B.1.1 implies that one would
> > not want to use privacy addresses in a P2P scenario, and then goes on
> > to talk about why you lose privacy.
> 

RFC 4941 never intended to get rid of constant IIDs, which would only make sense
if you got rid of constant higher-layer IDs like DNS names.  But this is the real world
where such higher-layer IDs are used all the time.

> I attend an IETF meeting, and learn the IID of your laptop. Then I can actively
> probe your node regarding "Is David at the office?" "Is David at home?",
> etc.... simply because your IID is known and constant.

Since you're making this personal... please explain how you can probe whether 
I'm at the office or at home, both of which are behind firewalls (so won't respond
to arbitrary probes) and have address prefixes you don't know to begin with.

Furthermore, how do you know I don't publish my addresses in a well-known
DNS name and hence want my node's location to be public?
(More generally, replace DNS name with any constant higher-layer ID.)
 
> > Windows has for the last 10 years used random (not MAC-derived) public
> > (not just temporary) addresses using the algorithm in 4941.
> 
> Which, as noted above, still brings you IIDs that are constant across networks
> -- and the corresponding implications.

I have yet to see a coherent threat model described for these
"implications".
 
> doesn't change the fact that that the scheme is flawed.

Have yet to see how.
 
> than a year (which is the "rough consensus" part of your quote above).

Not a great excuse.  There's plenty of other examples of documents that
were flawed for more than a year and the WG reversed direction.
(I could point to one recent one in the 6man WG but this is really off topic.)

> Actually, the analysis is: "I see no justification for employing an IID that is
> constant across networks, 

I provided you one in this thread, which you seem to have missed, so I'll
repeat it again.   If you have a constant higher-layer ID, such as a DNS name
that you keep up to date with your current public address, there's no value
in having an IID that varies by network.  It only adds extra complexity without
real value.   So the justification is "it works, it's widely deployed, and there's
no reason to change it in this particular case".

> nor do I see why should I embed my address".
> That's the philosophy (pro-activity?) one would expect to be applied.
> Otherwise you'll likely find out that there's this or that other mechanism or
> application which informs e.g. all configured addresses (e.g. ICMPv6 node
> information messages, to name one), and you realize that you should have
> done the right thing from starters.
> 
> I prefer to use terms such as stable vs. non-stable. -- At the end of the day,
> nothing prevents you from advertising a temporary address in the DNS, or
> *not* advertising a stable one in the DNS.
>
> I should probably s/server-like/receiving incoming connections/ -- although
> stable addresses are also useful when you want...er.. the addresses to be
> stable (prevent long-lived connections from breaking, etc.).
> 
> 
> 
> It's the other way around: you should find a very good reason for embedding
> a super-cookie in your addresses (whether based on the MAC address, r a
> random number). Unless you find one, you shouldn't.

Already answered above.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 May 2013 01:17:54 -0300

> whether or not the WG has consensus, the document is lacking in any case.

I'm always open for improvements. I personally believe that the current
version of the I-D is clear enough in that respect. In any case, since
you consider there's room for improvement, hopefully this email exchange
will either clarify things a bit and/or lead to improvements.

> e.g., DNS names, etc.

You are assuming those identifiers are there. But they needn't.

> So having constant addresses associated with 

I'm not sure why you bring this "higher-layer identifiers". The attack
vector I mentioned (actively polling possible addresses as opposed to
passively looking at IIDs still works pretty well without any sort of
higher-layer IID).

> remains to be *standardized*, which is the part I agree with.

I disagree it has been solved -- the only thing you've solved is
address-scanning.

> Windows does both, so is not "flawed" as you incorrectly conclude.

You don't mitigate tracking as long as you still keep some address with
constant IDs. The only thing that you "mitigate" with RFC 4941 is that
with RFC 4941 in place, the attacker can no longer "passively" track
you, but rather has to send some packet to cause you to use the address
that will leak your identity. -- Just firing a packet that will elicit a
response from that address is enough.

> So please elaborate on what you meant.

Let's say that your stable IID is 1111:2222:3333:4444:5555, and that,
for the sake of simplicity, the world consists of four networks:
2001:db8:1::/64, 2001:db8:2::/64, 2001:db8:3::/64, and 2001:db8:4::/64.

It thus becomes trivial to track you. Just periodically fire probe
packets to 2001:db8:1::1111:2222:3333:4444:5555,
2001:db8:2::1111:2222:3333:4444 (and so on), and the address that
responds leaks your location.

> (I of course understand motivation for preventing address scans.)

I couldn't understand any motivation for keeping them constant. And past
experience with virtually every ID you can think of indicates that, the
less predictable/constant such IDs are, the better.

> Remove superfluous text that confuses the issue. 

Agreed. Will fix this.

>  My point remains about
> temporary addresses not stable addresses).   

As noted above, the app can use any address it wants. But since the
stable address is still there, and attacker can cause the node to use
that stable address by simpl directing a packet to it.

> The text provides no clue

All the above said the main benefit that temporary addresses buy you is
trying to mitigate correlation of node activities within the same
network (which, at times, is not possible no matter whether your
addresses are temporary of not). In those cases where temporary
addressess are deemed to be unacceptable (from an ops perspective),
draft-ietf-6man-stable-privacy-addreses can result in an acceptable
tradeoff.

> where such higher-layer IDs are used all the time.

Such higher-layer IDs are not required for all apps.. And employing
constant IIDs hurts the privacy of nodes that are not using using such
higher-layer IDs.

> Since you're making this personal... 

It wasn't meant to.

> please explain how you can probe whether 

The fact that you clarify "Note: I'm behind a firewall" is pretty much
an implicit acknowledgement that the scheme you're using is flawed.

(With that logic, you can use any flawed scheme as long as you keep your
node unplugged from the net.)

You don't need any firewall to mitigate this attack vector if you
implement draft-ietf-6man-stable-privacy-addresses rather than the
scheme currently implemented by Windows.

> (More generally, replace DNS name with any constant higher-layer ID.)

Well, the challenge is in tracking nodes that we assume that do not want
to be tracked....

> in having an IID that varies by network. 

The onus is on you for wanting to keep them constant, rather than on me
for being proactive (and avoiding the kind of IDs that lead to flaws in
so many other protocols).

> It only adds extra complexity without

Sound pretty much sound like "It works -- as long as nobody wants to
exploit it --.. but our customers bought it anyway... so why should we
don't care?" to me.

That said, draft-ietf-6amn-stable-privacy-addresses doesn't obsolete the
traditional SLAAC IIDs, nor your non-standard approach... So you're free
to keep your stack "as is". In the same way that those who care about an
improved scheme, can implement it. It's a win-win situation, you might
say. :-)

FWIW, I know of at least three OSes that plan to implement
draft-ietf-6man-stableprivacy-addresses.

Thanks,

---

From: Tim Chown <[email-masked]>
Date: Wed, 22 May 2013 14:19:47 +0100

Hi Fernando,

I've read -07 and have some comments. Apologies if they are duplicates of previous comments.

Overall, I think this is good work and should be progressed.

First, some general comments:

You may wish to be clearer earlier in the document (abstract and/or introduction) that your method applies to all prefixes a host may have, including link-local, ULA, and global(s).  As it stands, you only, for example, mention link-locals first in Section 3.

The implication of the above is that a multihomed host will have different IIDs per ISP it receives a prefix from. This may have privacy advantages in a static device scenario (this is implied, but never stated anywhere that I can see).

There is some focus in your text on why you might disable 4941. That's not that common a practice, esp. in campus networks, or home networks. While some admins may wish to disable 4941 where they can, I think you should promote use of your method with 4941 being perfectly reasonable to use alongside it, rather than saying "because 4941 may be turned off, we need this method". Related, is that in a few places you talk about your method helping to reduce tracking between networks, while in practice using 4941 for static (desktop) devices does have benefits.

Specific comments:

Section 1: 

In the bullet point "since embedding" you may wish to be clearer that the "pattern" is the IID format caused by, for example, basing the IID on an IEEE identifier.

"other information collectors", I guess you mean sites running services, e.g. typically through web server logs.

Not sure what the point about inferring that temporary addresses are in use buys you.  Do you mean that with a small number of hosts in a subnet you may be able to deduce which devices are which by looking for when their addresses change?  That doesn't help you identify that same host later or in a different network though?

As an aside here, I looked in our network monitoring database, and my desktop Mac over the last month has been seen to use a link-local IPv6 address, many IPv6 privacy addresses, and an IPv4 global address, but not its global SLAAC address.  That's because nothing has connected to it from outside the local subnet. Sure, if we did not have an IPv6 firewall (as Dave pointed out) the host could be scannable due to its "predictable" Mac OUI, but it's interesting that in the last month, my global SLAAC address has never been used. Of course I don't happen to run any advertised services, though if I did my address would most likely be discoverable by looking at the DNS name it is referred to by.

Section 3:

Second main paragraph, you might add "just as per SLAAC today", or words to that effect. I don't think this is any change as such.

The Network_ID might perhaps in the future be some MIF-related provisioning domain identifier.  But your method does not preclude that.

Not sure about mentioning IIDs smaller than 64 bits here. You may wish to more clearly recommend that your method uses 64-bit IIDs?

"Including the SLAAC prefix"... you say the IID then varies across networks, but you may wish to add that the IID will also vary across each prefix the nodes uses (link-local, ULA, each global if multihomed).

There's a conflict in the next paragraph about "desirable" and "MUST" - which is it?

Perhaps you should state that you can never guarantee IID stability per prefix on any given interface, but your method seeks to honour that goal where it can.

The comment about MS Windows should perhaps be more orthogonal.  A node IID may be manually configured, it may use DHCP, it may use SLAAC with IEEE identifiers, it may use your method, it may use the method MS Windows uses, or it may even use the tokenised identifier method that I posted a while ago.  It can use any of those, AND use 4941 as well.  But saying "such implementations would not be affected by the method" doesn't sound quite right. 

Section 4:

Fourth main paragraph, what is the most likely cause of repeated DAD conflicts/failures?  NS/NA DoS?  Is there anything else that would be likely to cause this?  Worth elaborating on that when considering tuning the retry limit?

Section 7:

Maybe clarify that the first bullet point is for inbound connections only.

A fourth bullet point could be that you do not disclose hints about hardware types.

A fifth could be that IIDs may only be tracked or probed for each prefix the host is known to use, e.g. detection or disclosure of the link-local IID does not compromise the IID used for incoming global connections.  So if you sniff for IPv6 service discovery traffic, for example, you may learn a node's link-local IID, but not be able to deduce its global address.

How does your RA "attack" work in practice here?  Do you mean issuing a rogue RA for the same prefix?  We should perhaps assume that robust rogue RA protection is in place, and if not there are many worse things an attacker can do!

Perhaps note/remind here that RFC4862 says to run DAD per prefix (section 5.4).

Appendix B:

B.1 you say "one possible attack", then list more than one.

B.1.1 It will be interesting to see what emerging IPv6 "peer to peer" applications do. Do both ends use SLAAC/your method, both ends use 4941, or the "client" use 4941 and the "server" SLAAC/your method. 

B.1.3 Worth any consideration of MIPv6 here?  The Home Address is obviously trackable, by design, but any Care-of Address could benefit from your approach. Are there mobility methods anywhere else that might assume static IIDs though?

Tim

On 22 May 2013, at 05:17, Fernando Gont <[email-masked]> wrote:

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 May 2013 22:00:23 -0300

Hi, Tim,

Thanks so much for your feedback! -- Please find my comments in-line...

Thanks!

> You may wish to be clearer earlier in the document (abstract and/or
> introduction) that your method applies to all prefixes a host may
> have, including link-local, ULA, and global(s).  As it stands, you
> only, for example, mention link-locals first in Section 3.

Good point. I've tweaked the abstract, and have also clarified this
point in Section 3.

> The implication of the above is that a multihomed host will have
> different IIDs per ISP it receives a prefix from. This may have
> privacy advantages in a static device scenario (this is implied, but
> never stated anywhere that I can see).

So... how about a bullet along the lines of:

"Since the method specified in this document will result in different
Interface Identifiers, knowledge/leakage of the Interface Identifier
employed for the stable address of one prefix will not negatively affect
the security/privacy of the stable addresses configured for other prefixes"

> There is some focus in your text on why you might disable 4941.
> That's not that common a practice, esp. in campus networks, or home
> networks. While some admins may wish to disable 4941 where they can,
> I think you should promote use of your method with 4941 being
> perfectly reasonable to use alongside it, rather than saying "because
> 4941 may be turned off, we need this method". Related, is that in a
> few places you talk about your method helping to reduce tracking
> between networks, while in practice using 4941 for static (desktop)
> devices does have benefits.

I'm all for the use of this method along with RFC4941...I was just
noting that in some scenarios RFC4941 might be turned off not because a
non-desire for privacy, but for operational reasons.

I've tweaked the text a bit in the hopes that readers don't get the
impression that I'm arguing against use of RFC4941. (Most likely, by the
time you read this I'll have posted version -08... so please check that
one... and if there's still room for improvement in this area, I could
post a -09 version based on your suggestions).

> Specific comments:
> 
> Section 1:
> 
> In the bullet point "since embedding" you may wish to be clearer that
> the "pattern" is the IID format caused by, for example, basing the
> IID on an IEEE identifier.

I have added a clarification to that bullet. - Thanks!

> "other information collectors", I guess you mean sites running
> services, e.g. typically through web server logs.

This was borrowed from RFC 4941. -- anything to tweak here?

> Not sure what the point about inferring that temporary addresses are
> in use buys you. 

If you know that they are temporary addresses, you will expect them to
change. On the other hand, if temporary addresses looked exactly the
same as stable addresses, you'd have to figure out whether they are
different nodes, or the same node with a new temporary address.

> Do you mean that with a small number of hosts in a
> subnet you may be able to deduce which devices are which by looking
> for when their addresses change?

Yes.

> That doesn't help you identify that same host later or in a different network though?

If you can continually poll/see/communicate_with the node and detect the
address changes, you might still correlate the activities of a node
within a network (of course, when the number of nodes increases, and/or
the lifetime of temporary addresses is reduced, it gets much trickier).

The simple example would be:
Let's say you see two addresses on a given network. Say, 2001:db8::1 and
2001:db8::2. All out of the sudden you stop seeing packets from
2001:db8::2, but also start seeing packets from 2001:db8::10. -- It
would all look like 2001:db8::10 is the same node as 2001:db8::2.

> As an aside here, I looked in our network monitoring database, and my
> desktop Mac over the last month has been seen to use a link-local
> IPv6 address, many IPv6 privacy addresses, and an IPv4 global
> address, but not its global SLAAC address.  That's because nothing
> has connected to it from outside the local subnet. Sure, if we did
> not have an IPv6 firewall (as Dave pointed out) the host could be
> scannable due to its "predictable" Mac OUI, but it's interesting that
> in the last month, my global SLAAC address has never been used. Of
> course I don't happen to run any advertised services, though if I did
> my address would most likely be discoverable by looking at the DNS
> name it is referred to by.

The problem here is that once the stable address (or, more specifically,
its IID) becomes known to an attacker, you can be subject to
host-tracking by active probing. The stable IID might become known to an
attacker because at some point in time you advertised that IPv6 address,
but also because you e.g. shared a network with an attacker.

A simple example is that if we attend the same conference/cafe/whatever
and you could learn my stable IID (based on my MAC address). Then you
check the headers of my emails, and learn the v6 prefixes of the
networks I typically connect to. And, after that, you could tell whether
I am online by polling KnownPrefixes|IID.

An you shouldn't need a firewall to prevent *this*. Actually, strictly
speaking, the fireall won't prevent this: you can still probe the node
in different ways that the firewall won't block.

> Section 3:
> 
> Second main paragraph, you might add "just as per SLAAC today", or
> words to that effect. I don't think this is any change as such.

Agreed. I just wanted to clarify that the requirement of "MUST use this
method for all addresses" does not apply to temporary addresses -- since
they *can* be used in conjunction with
draft-ietf-6man-stable-privacy-addresses. -- I've moved the sentence you
mention right befre the parenthetical note.

> Not sure about mentioning IIDs smaller than 64 bits here. You may
> wish to more clearly recommend that your method uses 64-bit IIDs?

Previous versions of the I-D didn't. But then I was told that there was
no reason to hardcode the IID length in this I-D -- hence I tweaked the
text accordingly.

Although I agree that hardcoding the length of IIDs to be 64-bit long
makes the text clearer.

> "Including the SLAAC prefix"... you say the IID then varies across
> networks, but you may wish to add that the IID will also vary across
> each prefix the nodes uses (link-local, ULA, each global if
> multihomed).

I've tweaked the text accordingly.

> There's a conflict in the next paragraph about "desirable" and "MUST"

s/desirable/required/ :-) -- fixed!

> The comment about MS Windows should perhaps be more orthogonal.  A
> node IID may be manually configured, it may use DHCP, it may use
> SLAAC with IEEE identifiers, it may use your method, it may use the
> method MS Windows uses, or it may even use the tokenised identifier
> method that I posted a while ago.  It can use any of those, AND use
> 4941 as well.  But saying "such implementations would not be affected
> by the method" doesn't sound quite right.

The point I was trying to make is that traditional slaac (in terms of #
of nodes) is not as widely deployed as one would expect.

> Section 4:
> 
> Fourth main paragraph, what is the most likely cause of repeated DAD
> conflicts/failures?  NS/NA DoS?

Yes (of course, assuming 64-bit IIDs).

> Is there anything else that would be likely to cause this?  Worth 
> elaborating on that when considering tuning the retry limit?

My take is that, in a really unlucky scenario, you might get 1
collision, but no more than that. The value "3" is somewhat arbitrary, I
should say.

> Maybe clarify that the first bullet point is for inbound connections

That's correct if this is implemented along RFC4941. However, if this is
implemented without RFC4941, this method still prevents such trivial
host tracking.

> A fourth bullet point could be that you do not disclose hints about

Good point. Added!

> A fifth could be that IIDs may only be tracked or probed for each
> prefix the host is known to use, e.g. detection or disclosure of the
> link-local IID does not compromise the IID used for incoming global
> connections.  So if you sniff for IPv6 service discovery traffic, for
> example, you may learn a node's link-local IID, but not be able to
> deduce its global address.

Added as:

"Since the method specified in this document will result in different
Interface Identifiers, knowledge/leakage of the Interface Identifier
employed for the stable address of one prefix will not negatively affect
the security/privacy of the stable addresses configured for other prefixes"

> How does your RA "attack" work in practice here?  Do you mean issuing
> a rogue RA for the same prefix?  We should perhaps assume that robust
> rogue RA protection is in place, and if not there are many worse
> things an attacker can do!

Agreed. I added this attack vector description, since it was described
by Christian Huitema... so I added it for completeness sake. Should I
twek the text? Remove it?

> Perhaps note/remind here that RFC4862 says to run DAD per prefix

mmmm... not sure what you mean.

> B.1 you say "one possible attack", then list more than one.

Fixed.

> B.1.3 Worth any consideration of MIPv6 here?  

It has been years since I last checked MIPv6 (and when I did, I mostly
just skimmed through it). So... up to you. :-)

> The Home Address is
> obviously trackable, by design, but any Care-of Address could benefit
> from your approach. Are there mobility methods anywhere else that
> might assume static IIDs though?

You mean "IIDs that are stable across networks"?

P.S.: Please check version -08, and let me know if there are any further
tweaks I should apply.

Thanks so much!

Best regards,
-- 
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: Fri, 24 May 2013 11:31:16 +0200

> to arbitrary probes) and have address prefixes you don't know to begin with.

As noted, this wasn't meant to be personal -- it was just meant to be an
example.

Now, given the example under discussion:

I could learn your IID when we both attend the IETF meeting. And I could
learn your prefixes when you post to mailing-lists from such places.
Then I could use Prefix|IID to track you.

The fact that you use a firewall is mostly irrelevant. I'd bet your
firewall still reponds to some packets (e.g., packets with unsupported
options?). And, if that were not the case, I could rely on the
ICMPv6 "address resolution failed" error messages sent by your local
router (i.e., if I receive one of such messages, you're not there. If I
don't, you are).

I've seen similar discussions for different kinds of IDs in the past,
and every time someone pushed a flawed/sub-optimal approach, they got
bitten. Moral of the story: don't leak more than necessary to achieve
your desired goal, or you'll be bitten.

P.S.: This was discussed off-list already... but I posted this on-list
so that wg participants are aware of my response.

Cheers,

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 May 2013 12:45:31 +0100

> Then I could use Prefix|IID to track you.

Or you can sometimes get the user's IID in their home network via email headers, e.g.

Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::22]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4OBbV6x027652 (version=TLSv1/SSLv3 ...

Well, that's not a great example, but that information is available to anyone on a mail list you post to, though not usually in web archives of the same list.

> your desired goal, or you'll be bitten.

Indeed.  Which is why I was keen to see the "harvesting" methods also in the reconnaissance draft. 

Tim

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 May 2013 14:22:56 +0100

Hi,

In-line...

> the security/privacy of the stable addresses configured for other prefixes"

OK.

> post a -09 version based on your suggestions).

OK, I simply think that you were implying that because many enterprises will want to/try to disable 4941, that this was an argument for using stable privacy addresses.  In my view, I would certainly use stable privacy *and* 4941.

> This was borrowed from RFC 4941. -- anything to tweak here?

Maybe just add an example, ", e.g. such as addresses in web server logs, included in email headers, etc".

> different nodes, or the same node with a new temporary address.

OK, that's an advantage, but you could still deduce something from the addresses that change, and whether the address is used as a source or destination address.

> would all look like 2001:db8::10 is the same node as 2001:db8::2.

OK, but see above.

> in different ways that the firewall won't block.

Sure, the above was just an example. But Dave has a point, that if you have a default inbound policy at the edge, this type of exposure is unlikely, at least from network probes.  A similar argument to having protection against externally sourced ND exhaustion attacks the same way.  It may be worth stating this in the draft, as I'm sure others will point this out in the same way Dave has.

> Although I agree that hardcoding the length of IIDs to be 64-bit long

OK.

> of nodes) is not as widely deployed as one would expect.

Ah, OK.  I must run your script on my address samples some time :)

> Yes (of course, assuming 64-bit IIDs).

OK, I was wondering if you were implying something else.  That's fine.

> collision, but no more than that. The value "3" is somewhat arbitrary, I

OK.

> implemented without RFC4941, this method still prevents such trivial

OK, I always assume the former, but I appreciate many prefer to disable 4941 where they can.

> the security/privacy of the stable addresses configured for other prefixes"

OK.

> twek the text? Remove it?

I have no strong view, just noting that if a network permits rogue RAs, much worse things can happen.

> mmmm... not sure what you mean.

For each different IID generated.  Currently implementations *might* assume the IID is the same for link-local and global via traditional SLAAC.  RFC4862 notes that you should run DAD on all addresses.

> just skimmed through it). So... up to you. :-)

Well, nor me, but if you run MIPv6 you're by design wanting to be reachable by a persistent address. I guess at the very least you can say your method can apply when forming the Home Address during the initial bootstrap with the Home Agent. And when the host roams and gets a Care-of Address, the IID used to form the CoA at each visited network will be different, and different to the IID used for the HoA.  This I guess would reduce trackability as you roam, but would be good for a MIP guru to comment.

> You mean "IIDs that are stable across networks"?

Yes, just wondering.

Tim

---

From: t.petch <[email-masked]>
Date: Fri, 24 May 2013 16:04:14 +0100

Fernando

Looks good.

One more technical point, in a raft of lesser ones.

s1
/network, an  infer which addresses/network, and infer which addresses/

/(since the follow different patterns from that of traditional SLAAC
addresses),/
(since they follow different patterns from those of traditional SLAAC
addresses),/

s2
/When employed along "temporary addresses"/
When employed along with "temporary addresses"/

s3
/Identifiers (e.g. such as that specified in /
Identifiers (e.g. such as those specified in/

"Implementations conforming to this specification SHOULD provide the
   means for a system administrator to enable or disable the use of this
   algorithm for generating Interface Identifiers."
As and when the algorithm is disabled or enabled, should the box go back
and regenerate all its addresses?  The previous paragraph implies that
it is a MUST.

" starting from the rightmost bit."
Is that ambiguous?  Would least significant bit be clearer?

"Key lengths of at least 128 bits should be"
Should that be with an entropy of 128 bits?  1024 bit keys are not
always as strong as they first appear:-(

s.7
/limit the ability of an attacker from successfully performing /
limit the ability of an attacker to successfully perform/

Tom Petch

----- Original Message -----
From: "Fernando Gont" <[email-masked]>
To: "Tim Chown" <[email-masked]>
Cc: <[email-masked]>; "Fernando Gont"
<[email-masked]>; <[email-masked]>
Sent: Friday, May 24, 2013 2:00 AM

---

From: Dave Thaler <[email-masked]>
Date: Fri, 24 May 2013 22:04:03 +0000

Thanks Alissa for the nice table, this is very helpful.

> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Friday, May 24, 2013 2:34 PM
> To: Fernando Gont
> Cc: Dave Thaler; [email-masked]; [email-masked]; Brian
> Haberman; Ray Hunter; tom.petch; Christian Huitema; He Xuan
> This discussion got me thinking about how to be rigorous in articulating the
> specific threats that different kinds of addresses do and do not mitigate. I put
> together a little table to try to sum this up:
> http://www.alissacooper.com/files/IPv6-address-threats.pdf
> 
> The table assumes, for simplicity, that the node in question doesn't use any
> higher-layer identifiers and is never behind a firewall.
> 
> I think I've seen four different kinds of threats described in the course of the
> discussion of this draft, listed as the columns in the table:
> (a) A typical address scanning attack for the purpose of exploiting the nodes
> found by scanning
> (b) An attack that involves scanning an address space, identifying which nodes
> respond, and subsequently tracking the locations of those nodes. I'm not
> exactly sure what the point of doing this is, so maybe it shouldn't be included,
> but I left it in.
> (c) An attack wherein the attacker receives a node's address through some
> channel (email, p2p serving, etc.) and then tracks the location of that node
> later.
> (d) An attack wherein the attacker receives a node's address through some
> channel and then correlates the node's activities together.

I'm assuming here by (d) you mean correlation over_time_ of activities from the
same node, even if it never moves.

> 
> The rows of the table are the address generation methods that have been
> discussed. The first three are for nodes that only use stable addresses and
> never use temporary addresses. Incidentally, I assume that it is this kind of
> configuration that Fernando's draft is targeting -- the scenario where a
> network administrator has disabled temporary addresses regardless of the
> desires of the user, as described in section 1 of the draft. As can be seen in
> the table, both random and random-per-network (my term for what the draft
> calls stable privacy addresses) mitigate both types of address scanning attacks.
> Random-per-network additionally mitigates location tracking and potentially
> reduces the amount of time over which correlation can take place.
> 
> The second group of three are for nodes that only use temporary addresses
> (but that also configure a stable address that never gets used). This is what
> would be expected by users that want to avoid correlation attacks, assuming
> their admins allow it. In this case random and random-per-network provide
> equivalent protection.
> 
> The last group of three are for nodes that use both temporary and stable
> addresses. Again here both random and random-per-network prevent the
> first two attacks, but random-per-network also prevents location tracking and
> potentially reduces the scope for correlation.
> 
> I think the conclusion from this is that if there are lots of nodes out there that
> want to be protected from location tracking and correlation but their admins
> won't let them use temporary addresses, then random-per-network (row 3)
> provides some benefits over random (row 2).

Also, for nodes that never move (e.g., servers, desktop PCs, etc.) random and
random-per-network are equivalent.

>
> If we're talking about the case
> where a node can use temporary addresses and only uses them, random and
> random-per-network provide the same benefits (rows 5 and 6). I'm assuming
> those are the two common cases (could be wrong though).
> 
> If we take away the assumption that the node uses no higher-layer identifiers,
> then correlation becomes possible in all of the cases for the duration of
> max(life of higher-layer identifier, longest-lived address).

Agree.

> 
> If we take away the assumption that the node is never behind a firewall and
> assume that it will never respond to unsolicited packets (maybe too much too
> assume, but let's try), then the only differences between the address
> generation mechanisms are with respect to correlation. Random-per-network
> still provides some benefits over random in this case.

Agree.  For nodes that move between networks, yes.
Nodes that never move don't gain those benefits of course.

> 
> Not sure if this is helpful to anyone else, but it clarified my thinking on this a
> bit, and it might be worth making the threat analysis in the draft more specific
> along these lines.

I think it would definitely help the draft to include this analysis.

Thanks again,
-Dave

> 
> Alissa
> 
> On May 24, 2013, at 5:31 AM, Fernando Gont <[email-masked]>
> wrote:
> 
> >>> I attend an IETF meeting, and learn the IID of your laptop. Then I
> >>> can actively probe your node regarding "Is David at the office?" "Is
> >>> David at home?", etc.... simply because your IID is known and constant.
> >>
> >> Since you're making this personal... please explain how you can probe
> >> whether I'm at the office or at home, both of which are behind
> >> firewalls (so won't respond to arbitrary probes) and have address prefixes
> you don't know to begin with.
> >
> > As noted, this wasn't meant to be personal -- it was just meant to be
> > an example.
> >
> > I could learn your IID when we both attend the IETF meeting. And I
> > could learn your prefixes when you post to mailing-lists from such places.
> > router (i.e., if I receive one of such messages, you're not there. If
> > I don't, you are).
> >

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 24 May 2013 22:19:08 +0000

> correlation but their admins won't let them use temporary addresses, 
> then random-per-network (row 3) provides some benefits over random (row 2).

So is the goal of the draft to give a new way for network administrators to decrease privacy of users? If yes, then if this goal was removed, would the rest of the outlined benefits still warrant the proposed type of addresses?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Friday, May 24, 2013 3:04 PM
To: Alissa Cooper; Fernando Gont
Cc: [email-masked]; Brian Haberman; [email-masked]; Ray Hunter; tom.petch; Christian Huitema; He Xuan
Subject: RE: Comments on draft-ietf-6man-stable-privacy-addresses-07

> This discussion got me thinking about how to be rigorous in 
> articulating the specific threats that different kinds of addresses do 
> and do not mitigate. I put together a little table to try to sum this up:
> The table assumes, for simplicity, that the node in question doesn't 
> use any higher-layer identifiers and is never behind a firewall.
> 
> I think I've seen four different kinds of threats described in the 
> course of the discussion of this draft, listed as the columns in the table:
> (a) A typical address scanning attack for the purpose of exploiting 
> the nodes found by scanning
> (b) An attack that involves scanning an address space, identifying 
> which nodes respond, and subsequently tracking the locations of those 
> nodes. I'm not exactly sure what the point of doing this is, so maybe 
> it shouldn't be included, but I left it in.
> (c) An attack wherein the attacker receives a node's address through 
> some channel (email, p2p serving, etc.) and then tracks the location 
> of that node later.
> (d) An attack wherein the attacker receives a node's address through 
> some channel and then correlates the node's activities together.

I'm assuming here by (d) you mean correlation over_time_ of activities from the same node, even if it never moves.

> 
> The rows of the table are the address generation methods that have 
> been discussed. The first three are for nodes that only use stable 
> addresses and never use temporary addresses. Incidentally, I assume 
> that it is this kind of configuration that Fernando's draft is 
> targeting -- the scenario where a network administrator has disabled 
> temporary addresses regardless of the desires of the user, as 
> described in section 1 of the draft. As can be seen in the table, both 
> random and random-per-network (my term for what the draft calls stable privacy addresses) mitigate both types of address scanning attacks.
> Random-per-network additionally mitigates location tracking and 
> potentially reduces the amount of time over which correlation can take place.
> 
> The second group of three are for nodes that only use temporary 
> addresses (but that also configure a stable address that never gets 
> used). This is what would be expected by users that want to avoid 
> correlation attacks, assuming their admins allow it. In this case 
> random and random-per-network provide equivalent protection.
> 
> The last group of three are for nodes that use both temporary and 
> stable addresses. Again here both random and random-per-network 
> prevent the first two attacks, but random-per-network also prevents 
> location tracking and potentially reduces the scope for correlation.
> 
> I think the conclusion from this is that if there are lots of nodes 
> out there that want to be protected from location tracking and 
> correlation but their admins won't let them use temporary addresses, 
> then random-per-network (row 3) provides some benefits over random (row 2).

Also, for nodes that never move (e.g., servers, desktop PCs, etc.) random and random-per-network are equivalent.

> where a node can use temporary addresses and only uses them, random 
> and random-per-network provide the same benefits (rows 5 and 6). I'm 
> assuming those are the two common cases (could be wrong though).
> 
> If we take away the assumption that the node uses no higher-layer 
> identifiers, then correlation becomes possible in all of the cases for 
> the duration of max(life of higher-layer identifier, longest-lived address).

Agree.

> 
> If we take away the assumption that the node is never behind a 
> firewall and assume that it will never respond to unsolicited packets 
> (maybe too much too assume, but let's try), then the only differences 
> between the address generation mechanisms are with respect to 
> correlation. Random-per-network still provides some benefits over random in this case.

> 
> Not sure if this is helpful to anyone else, but it clarified my 
> thinking on this a bit, and it might be worth making the threat 
> analysis in the draft more specific along these lines.

Thanks again,
-Dave

> >>> can actively probe your node regarding "Is David at the office?" 
> >>> "Is David at home?", etc.... simply because your IID is known and constant.
> >>
> >> Since you're making this personal... please explain how you can 
> >> probe whether I'm at the office or at home, both of which are 
> >> behind firewalls (so won't respond to arbitrary probes) and have 
> >> address prefixes
> > As noted, this wasn't meant to be personal -- it was just meant to 
> > be an example.
> >
> > firewall still reponds to some packets (e.g., packets with 
> > unsupported options?). And, if that were not the case, I could rely 
> > on the
> > router (i.e., if I receive one of such messages, you're not there. 
> > If I don't, you are).
> >
> > I've seen similar discussions for different kinds of IDs in the 
> > past, and every time someone pushed a flawed/sub-optimal approach, 
> > they got bitten. Moral of the story: don't leak more than necessary 
> > to achieve your desired goal, or you'll be bitten.
> >
> > P.S.: This was discussed off-list already... but I posted this 
> > on-list so that wg participants are aware of my response.
> >
> > Cheers,
> > --
> > Fernando Gont
> > SI6 Networks

---

From: Dave Thaler <[email-masked]>
Date: Fri, 24 May 2013 22:19:44 +0000

I'd also like to see CGAs (3972) added to this analysis.  It seems to me they're
the existing standards-track "random-per-network" addresses.  So all of the
"random-per-network" statements would seem apply equally to the existing RFC.

This draft references that RFC but does not contain any discussion on the
relative use cases.  I.e., if I already use CGAs for my "random-per-network"
solution, is there any benefit in this draft?

What problem is this solving that wasn't already solved by that existing 
Proposed Standard RFC?

-Dave

> > random and random-per-network (my term for what the draft calls stable
> privacy addresses) mitigate both types of address scanning attacks.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 May 2013 10:28:29 +1200

> Thanks Alissa for the nice table, this is very helpful.

Agreed. Two points though:

1. It seems to me that location tracking to the level of the 64-bit
prefix is *always* possible, which may well identify a specific
customer and/or physical location, but not a specific host and/or
user. That qualifies column (c).

2. For completeness, include static manual addresses (yes, they
still exist in IPv6), which presumably get "possible" in every
column.

   Brian

---

From: Dave Thaler <[email-masked]>
Date: Fri, 24 May 2013 22:29:52 +0000

[...]
> The fact that you use a firewall is mostly irrelevant. I'd bet your firewall still
> reponds to some packets (e.g., packets with unsupported options?).
[..]

No, the Windows firewall doesn't allow any ICMP responses to unsolicited traffic,
they're all dropped.  This is what is sometimes called "stealth mode".

> And, if
> that were not the case, I could rely on the
> ICMPv6 "address resolution failed" error messages sent by your local router
> (i.e., if I receive one of such messages, you're not there. If I don't, you are).

Ok, yes that one is interesting.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Fri, 24 May 2013 22:43:28 +0000

It also now occurs to me that since RFC 3972 has IPR disclosures from both 
Microsoft and Ericsson, those disclosures may or may not apply to
draft-ietf-6man-stable-privacy-addresses as well.

Per the Note Well, I'm at least sending this email, but will check with
Microsoft folks to see whether an IPR statement would be needed on 
this draft (personally I have no clue).

I'd suggest that any Ericsson folks paying attention might need to do the same.

-Dave

> From: Dave Thaler
> Sent: Friday, May 24, 2013 3:20 PM
> To: Dave Thaler; Alissa Cooper; Fernando Gont
> > Cc: [email-masked]; Brian Haberman; [email-masked]; Ray
> > Hunter; tom.petch; Christian Huitema; He Xuan
> > > articulating the specific threats that different kinds of addresses
> > > do and do not mitigate. I put together a little table to try to sum this up:
> > > which nodes respond, and subsequently tracking the locations of
> > > those nodes. I'm not exactly sure what the point of doing this is,
> > > so maybe it shouldn't be included, but I left it in.
> > I'm assuming here by (d) you mean correlation over_time_ of activities
> > from the same node, even if it never moves.
> >
> > >
> > > described in section 1 of the draft. As can be seen in the table,
> > > both random and random-per-network (my term for what the draft calls
> > > stable
> > > potentially reduces the amount of time over which correlation can
> > > take
> > place.
> > >
> > Also, for nodes that never move (e.g., servers, desktop PCs, etc.)
> > random and random-per-network are equivalent.
> >
> > >
> > > identifiers, then correlation becomes possible in all of the cases
> > > for the duration of max(life of higher-layer identifier, longest-lived
> address).
> >
> > Agree.
> >
> > >
> > > firewall and assume that it will never respond to unsolicited
> > > packets (maybe too much too assume, but let's try), then the only
> > > differences between the address generation mechanisms are with
> > > respect to correlation. Random-per-network still provides some
> > > benefits over random
> > in this case.
> >
> > > >>> I attend an IETF meeting, and learn the IID of your laptop. Then
> > > >>> I can actively probe your node regarding "Is David at the office?"
> > > >>> "Is David at home?", etc.... simply because your IID is known
> > > >>> and
> > constant.
> > > >>
> > > > The fact that you use a firewall is mostly irrelevant. I'd bet
> > > > your firewall still reponds to some packets (e.g., packets with
> > > > unsupported options?). And, if that were not the case, I could
> > > > rely on the
> > > > ICMPv6 "address resolution failed" error messages sent by your
> > > > local router (i.e., if I receive one of such messages, you're not there.
> > > > If I don't, you are).
> > > >
> > > > they got bitten. Moral of the story: don't leak more than
> > > > necessary to achieve your desired goal, or you'll be bitten.
> > > >

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 24 May 2013 17:33:30 -0400

This discussion got me thinking about how to be rigorous in articulating the specific threats that different kinds of addresses do and do not mitigate. I put together a little table to try to sum this up: http://www.alissacooper.com/files/IPv6-address-threats.pdf

The table assumes, for simplicity, that the node in question doesn't use any higher-layer identifiers and is never behind a firewall. 

I think I've seen four different kinds of threats described in the course of the discussion of this draft, listed as the columns in the table:
(a) A typical address scanning attack for the purpose of exploiting the nodes found by scanning
(b) An attack that involves scanning an address space, identifying which nodes respond, and subsequently tracking the locations of those nodes. I'm not exactly sure what the point of doing this is, so maybe it shouldn't be included, but I left it in.
(c) An attack wherein the attacker receives a node's address through some channel (email, p2p serving, etc.) and then tracks the location of that node later.
(d) An attack wherein the attacker receives a node's address through some channel and then correlates the node's activities together.

The rows of the table are the address generation methods that have been discussed. The first three are for nodes that only use stable addresses and never use temporary addresses. Incidentally, I assume that it is this kind of configuration that Fernando's draft is targeting -- the scenario where a network administrator has disabled temporary addresses regardless of the desires of the user, as described in section 1 of the draft. As can be seen in the table, both random and random-per-network (my term for what the draft calls stable privacy addresses) mitigate both types of address scanning attacks. Random-per-network additionally mitigates location tracking and potentially reduces the amount of time over which correlation can take place.

The second group of three are for nodes that only use temporary addresses (but that also configure a stable address that never gets used). This is what would be expected by users that want to avoid correlation attacks, assuming their admins allow it. In this case random and random-per-network provide equivalent protection.

The last group of three are for nodes that use both temporary and stable addresses. Again here both random and random-per-network prevent the first two attacks, but random-per-network also prevents location tracking and potentially reduces the scope for correlation.

I think the conclusion from this is that if there are lots of nodes out there that want to be protected from location tracking and correlation but their admins won't let them use temporary addresses, then random-per-network (row 3) provides some benefits over random (row 2). If we're talking about the case where a node can use temporary addresses and only uses them, random and random-per-network provide the same benefits (rows 5 and 6). I'm assuming those are the two common cases (could be wrong though).

If we take away the assumption that the node uses no higher-layer identifiers, then correlation becomes possible in all of the cases for the duration of max(life of higher-layer identifier, longest-lived address).

If we take away the assumption that the node is never behind a firewall and assume that it will never respond to unsolicited packets (maybe too much too assume, but let's try), then the only differences between the address generation mechanisms are with respect to correlation. Random-per-network still provides some benefits over random in this case.

Not sure if this is helpful to anyone else, but it clarified my thinking on this a bit, and it might be worth making the threat analysis in the draft more specific along these lines.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 25 May 2013 07:00:21 -0400

I made updates in response to this email and Dave's emails and made the table publicly viewable and editable if folks want to make further changes themselves: https://docs.google.com/spreadsheet/ccc?key=0Au4OS7RZgZwHdHozNzNHdUNtVEJSNlo3N3NFMG5Wa1E&usp=sharing

---

From: Fernando Gont <[email-masked]>
Date: Sun, 26 May 2013 08:13:18 +0200

Dave,

What does draft-ietf-6man-stable-privacy-addresses has to do with CGAs?

Has MS or Ericsson patented the use of PRFs?

Have you guys any IPR on RFC1948? -- Because
draft-ietf-6man-stableprivacy-addresses is essentially Bellovin's
RFC1948 applied to IPv6 addresses.

Thanks,
Fernando

---

From: Fernando Gont <[email-masked]>
Date: Sun, 26 May 2013 14:46:56 +0200

> What problem is this solving that wasn't already solved by that existing 

I could give you multiple reasons for
draft-ietf-6manstable-privacy-addresses:

* The whole point of CGAs is validating the ownership of an IPv6
address. If you're going to use CGAs for that, that's overkill
(bothering with a public key, etc., etc.)

* CGAs are more complex and difficult to undestand. OTOH, if one
understands RFC1948 or how a hash function works, understanding
draf-tietf-6man-stable-privacy-addresses is straightforward.

* CGAs are far more expensive than
draft-ietf-6man-stable-privacy-addresses. You compute at least two
hashes, where in stable privacy you need only one.

* CGAs require a specific hash algorithm (SHA-1), since they neey other
to be able to verify the CGA. We give implementations to employ the
algorithm they feel is more appropriate (based on their specific tradeoffs).

* CGAs are IPR encumbered. draft-ietf-6man-stable-privacy-addresses are not.

* CGAs cannot be used in conjunction with RFC4941.

To be honest, the argument of "using CGAs instead of stable privacy"
sounds to me pretty much like "you don't need a hammer, because you can
use pliers to knock the nail".

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 26 May 2013 14:49:54 +0200

> Ok, yes that one is interesting.

An attacker just needs one vector to be successful. And at the point
such vector is not under your control (as in this case), all bets are off.

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 26 May 2013 15:01:36 +0200

HI Alissa,

Thanks for posting this. Please find my comments inline...

On 05/24/2013 11:33 PM, Alissa Cooper wrote:
> targeting 

Nope. We're improving stable addresses. Whether you use RFC4941 or not
is pretty much orthogonal.

>-- the scenario where a network administrator has disabled
> stable privacy addresses) mitigate both types of address scanning
> attacks. Random-per-network additionally mitigates location tracking
> and potentially reduces the amount of time over which correlation can
> take place.

This assessment is correct. Note, however, that stable privacy addresses
are also meant to be used in conjunction with rfc4941.

> random and random-per-network provide equivalent protection.

The problem here is that the assumption of "never gets used" is not
correct. Or, well, you might argue "is not intentionally used for
legitimate purposes".

An attacker can trigger the use of such addresses, e.g., y sending his
probe packets to the stable address.

> (row 2). If we're talking about the case where a node can use
> temporary addresses and only uses them, random and random-per-network
> provide the same benefits (rows 5 and 6). I'm assuming those are the
> two common cases (could be wrong though).

Please see above.

> correlation. Random-per-network still provides some benefits over

As noted, it is always possible to probe such node. e.g., rely on ICMPv6
"address resolution failed" from the local router at the victim cite to
tell whether the node is there or not.

> analysis in the draft more specific along these lines.

How about including something along these lines (*) in an Appendix?

(*) Discussion of possible attacks, and what stable privacy addresses do
about them (analyzing this for every possible address generation
mechanism would be out of scope for this I-D, IMO).

Thanks!

Best regards,

---

From: SM <[email-masked]>
Date: Sun, 26 May 2013 11:53:57 -0700

>I'd suggest that any Ericsson folks paying attention might need to 

draft-ietf-6man-stable-privacy-addresses-00 was submitted as a 
working group document in May 2012.  There was a Last Call in April 
2013.  The Acknowledgement Section clearly says that the algorithm 
specified in the draft has been inspired by RFC 1948.  There isn't 
any IPR disclosure filed against RFC 1948.

Does draft-ietf-6man-stable-privacy-addresses have to wait for IPR 
disclosures, if any, to be filed before it is moved forward?

Could someone provide a summary of the issues for 
draft-ietf-6man-stable-privacy-addresses-08?

Thanks,
-sm

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 28 May 2013 17:07:37 -0400

Hi Fernando,

Comments inline.

> is pretty much orthogonal.

Fair enough.

> correct. Or, well, you might argue "is not intentionally used for

Intentionally used is what I was going for, since some of the discussion about the choice of address generation mechanism revolves around intention. That is, some implementations/users might choose temporary addresses for specific reasons, sys admins might choose to disable them for specific reasons, etc.

> probe packets to the stable address.

In the case of a node that only intentionally uses temporary addresses, are there other uses you envision of that node's stable address besides the attacks in (a) and (b) in the table?

>> two common cases (could be wrong though).

Not sure what this means -- in terms of the user's intent, I assume most users intend to either use a stable address all the time or use temporary addresses all the time.

> mechanism would be out of scope for this I-D, IMO).

Agreed. However, even with the appendix, there are still some places where the discussion of the threat models in section 1 could be clearer, IMO. For example:

      However, even with temporary addresses [RFC4941] in place,
      preventing correlation of activities of a node within a network
      may be difficult (if at all possible) to achieve.  As a trivial
      example, consider a scenario where there is a single node (or a
      reduced number of nodes) connected to a specific network.  An
      attacker could detect new addresses in use at that network, an
      infer which addresses are being employed by which hosts.  This
      task is made particularly easier by the fact that use of
      "temporary addresses" can be easily inferred (since the follow
      different patterns from that of traditional SLAAC addresses), and
      since they are re-generated periodically (i.e., after a specific
      amount of time has elapsed).

My read of this is that you're talking about either (1) a situation where a node has a globally unique prefix, or (2) a situation where a small number of nodes share the same prefix and an attacker can disambiguate them using some other information about their behavior besides their IP addresses. Is that right? If that's the case, isn't correlation possible regardless of how the suffix is generated? The document seems to imply that nodes with temporary addresses are more susceptible to these two situations than nodes that use other address generation mechanisms, when in fact the first situation (globally unique prefix) probably affects all nodes equally regardless of generation mechanism, and in the second situation the fact that temporary addresses refresh frequently might erect a barrier that makes correlation more difficult and that would not exist with random or random-per-network addresses.

Another point for clarification:

   On the other hand, in scenarios in which "temporary addresses" are employed
   together with stable addresses such as those based on IEEE
   identifiers, implementation of the mechanism described in this
   document would mitigate address-scanning attacks and also mitigate
   some vectors for correlating host activities that are not mitigated
   by the use of temporary addresses.

Which correlation attack vectors do random-per-network addresses mitigate that temporary addresses do not? In the analysis in column (d) of the table, the correlation entries are the same for all of the address generation mechanisms in cases where the node intentionally uses temporary addresses. 

Thanks,
Alissa

---

From: Dave Thaler <[email-masked]>
Date: Wed, 29 May 2013 02:00:55 +0000

> Sent: Saturday, May 25, 2013 11:13 PM
> To: Dave Thaler
> Cc: Alissa Cooper; [email-masked]; Brian Haberman;
> [email-masked]; Ray Hunter; tom.petch; Christian Huitema; He Xuan

1) Both give "random-per-network" addresses, using Alissa's terminology.
2) Both generate an IP address using a secret + a network prefix + a DAD counter + other information.

So it comes down to what was claimed, which I don't know offhand.

> Has MS or Ericsson patented the use of PRFs?

Pseudorandom functions themselves are well known.  Some folks (don't know) might
have patented using PRFs in novel ways to do specific things.

> Have you guys any IPR on RFC1948? -- Because draft-ietf-6man-stableprivacy-
> addresses is essentially Bellovin's

I'm not personally familiar with RFC1948 so will leave that to others to answer.

-Dave

> > It also now occurs to me that since RFC 3972 has IPR disclosures from
> > both Microsoft and Ericsson, those disclosures may or may not apply to
> > Per the Note Well, I'm at least sending this email, but will check
> > with Microsoft folks to see whether an IPR statement would be needed
> > on this draft (personally I have no clue).
> >

---

From: Dave Thaler <[email-masked]>
Date: Wed, 29 May 2013 02:03:16 +0000

> >> [...] I could rely on the
> >> router (i.e., if I receive one of such messages, you're not there. If I don't,
> you are).
> >
> An attacker just needs one vector to be successful.

Agree.  Putting the above example vector into the draft would help the reader
understand the motivation for the problem.

-dave

---

From: Tim Chown <[email-masked]>
Date: Wed, 29 May 2013 09:44:21 +0100

> My read of this is that you're talking about either (1) a situation where a node has a globally unique prefix, or (2) a situation where a small number of nodes share the same prefix and an attacker…

A static global prefix for IPv6 is not that dissimilar to a static IPv4 address with NAT for IPv4.  You can correlate the home, for example, not necessarily devices within it.

If devices rotate their 4941 address at fixed intervals, then you might be able to infer which devices are which from noting the number of addresses in use, and changes in addresses over time (e.g. old privacy address not seen for an outbound SYN, new address is seen).   in principle the use of "TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR" for the refresh should provide some variation.  In practice, the implementations I've observed seem pretty regular.  More variation could be good in this respect.  But that's not the topic for this draft.

> Which correlation attack vectors do random-per-network addresses mitigate that temporary addresses do not? In the analysis in column (d) of the table, the correlation entries are the same for all o…

If you use 4941 for outbound connections, and IEEE SLAAC default for inbound, then your IEEE based address is more readily guessable than had you used a stable privacy address.

The above is currently the default for most IPv6 devices; 4941 support is now very common, and usually on by default.

What is rarer (very rare?) is using 4941 addresses to initiate *and* receive new connections.  I think that's the type of case that draft-rafiee-6man-ra-privacy discusses/proposes.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2013 19:07:01 +0200

> 1) Both give "random-per-network" addresses, using Alissa's terminology.

CGA's doesn't seem to aim at stable-per-network addresses. For instance,
the modifier is expected to be random.

> 2) Both generate an IP address using a secret + a network prefix + a DAD counter + other information.

But both have completely different goals. CGAs have the goal of encoding
a public key, whereas stable-privacy has the goal of producing
meaningles random bits.

> have patented using PRFs in novel ways to do specific things.

What I did was to apply Bellovin's RFC1948. So any IPR claim on
draft-ietf-6man-stable-addresses that predates RFC1948 and that's is not
Bellovin's is claiming credit for somebody else's work.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 May 2013 17:28:56 +0200

> understand the motivation for the problem.

Isn't it enough simply noting that the target node can be probed?
Getting into the specific details of the probe packet
(stimulus/response) seems like "over-specifying" things to me...

Cheers,

---

From: Dave Thaler <[email-masked]>
Date: Thu, 30 May 2013 16:09:19 +0000

> Sent: Thursday, May 30, 2013 8:29 AM
> To: Dave Thaler
> Cc: [email-masked]; Brian Haberman; [email-masked]; Ray Hunter;
> Alissa Cooper; Christian Huitema; tom.petch; He Xuan
> >>>> local router (i.e., if I receive one of such messages, you're not
> >>>> there. If I don't,
> >> you are).
> >>>
> > Agree.  Putting the above example vector into the draft would help the
> > reader understand the motivation for the problem.
> 

My opinion is that this example is important, since the example is
one where there's nothing the target node itself can do about it,
which is non-obvious.   Otherwise readers could be as confused as
I was.  So pointing it out adds significant clarity.

-Dave

---

From: Fernando Gont <[email-masked]>
Date: Fri, 31 May 2013 12:53:34 +0200

> I was.  So pointing it out adds significant clarity.

Ok. Will do.

Thanks!

Best regards,

---

From: Nalini Elkins <[email-masked]>
Date: Fri, 31 May 2013 05:32:25 -0700 (PDT)

All,

Please comment on a new Destination Option that we are proposing:

https://datatracker.ietf.org/doc/draft-elkins-6man-ipv6-pdm-dest-option/

There are two documents which give the background:

https://datatracker.ietf.org/doc/draft-elkins-v6ops-ipv6-end-to-end-rt-needed/

https://datatracker.ietf.org/doc/draft-elkins-v6ops-ipv6-packet-sequence-needed/

And one which gives the recommended usage of this destination option:

https://datatracker.ietf.org/doc/draft-elkins-v6ops-ipv6-pdm-recommended-usage/

We will be contacting the 6Man chairs to get on the agenda for Berlin.

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

---

From: Nalini Elkins <[email-masked]>
Date: Fri, 31 May 2013 05:32:25 -0700 (PDT)

All,

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

---

From: Fernando Gont <[email-masked]>
Date: Sat, 01 Jun 2013 00:35:31 +0200

On 05/24/2013 03:22 PM, Tim Chown wrote:
>> impression that I'm arguing against use of RFC4941. (Most likely,
>> by the time you read this I'll have posted version -08... so please
>> check that one... and if there's still room for improvement in this
>> area, I could post a -09 version based on your suggestions).
> 
> OK, I simply think that you were implying that because many 
> enterprises will want to/try to disable 4941, that this was an 
> argument for using stable privacy addresses.  In my view, I would 
> certainly use stable privacy *and* 4941.

I would use stable privacy and RFC 4941, too.

What I tried to convey in the text was something like "we need to
improve the stable addresses. This scheme have these benefits, which
complement those of rfc4941... That aside, in those scenarios where
rfc4941 is disabled, implementing this will bring you these benefits,
and provide an interesting trade-off for folks that disable rfc4941".

Me, i'm in favor of having stable privacy + RFC 4941. Applications are
in a better position of deciding which type of address is better for
them. But I understand that folks operating e.g. enterprise networks may
have valid reasons to disable rfc4941.

> logs, included in email headers, etc".

Ok, done.

>>> Not sure what the point about inferring that temporary addresses 
>>> are in use buys you.
>> 
>> If you know that they are temporary addresses, you will expect
>> them to change. On the other hand, if temporary addresses looked
>> exactly the same as stable addresses, you'd have to figure out
>> whether they are different nodes, or the same node with a new
>> temporary address.
> 
> OK, that's an advantage, but you could still deduce something from 
> the addresses that change, and whether the address is used as a 
> source or destination address.

Agreed.

[context: talking about mac-based addreses not used much in practice]
>> 
>> The problem here is that once the stable address (or, more 
>> specifically, its IID) becomes known to an attacker, you can be 
>> subject to host-tracking by active probing. The stable IID might 
>> become known to an attacker because at some point in time you 
>> advertised that IPv6 address, but also because you e.g. shared a 
>> network with an attacker.
>> 
>> A simple example is that if we attend the same 
>> conference/cafe/whatever and you could learn my stable IID (based 
>> on my MAC address). Then you check the headers of my emails, and 
>> learn the v6 prefixes of the networks I typically connect to. And, 
>> after that, you could tell whether I am online by polling 
>> KnownPrefixes|IID.
>> 
>> An you shouldn't need a firewall to prevent *this*. Actually, 
>> strictly speaking, the fireall won't prevent this: you can still 
>> probe the node in different ways that the firewall won't block.
> 
> Sure, the above was just an example. But Dave has a point, that if 
> you have a default inbound policy at the edge, this type of exposure 
> is unlikely, at least from network probes. 

Would relying on something that is not under your control be a wise
thing to do?

> A similar argument to 
> having protection against externally sourced ND exhaustion attacks 
> the same way.  It may be worth stating this in the draft, as I'm
> sure others will point this out in the same way Dave has.

I'm of the idea that if your implementations suffers from ND exhaustion
attacks, you should fix it. -- Temporary mitigations are okay (operators
need a quick fix they can apply now), as long as the origin of the
problem is tackled, too.

>>> SLAAC with IEEE identifiers, it may use your method, it may use
>>> the method MS Windows uses, or it may even use the tokenised 
>>> identifier method that I posted a while ago.  It can use any of 
>>> those, AND use 4941 as well.  But saying "such implementations 
>>> would not be affected by the method" doesn't sound quite right.
>> 
>> The point I was trying to make is that traditional slaac (in terms 
>> of # of nodes) is not as widely deployed as one would expect.
> 

Please do. :-) -- BTW, ISOC's Mat Ford did, already (have you seen it?).

>> That's correct if this is implemented along RFC4941. However, if 
>> this is implemented without RFC4941, this method still prevents 
>> such trivial host tracking.
> 

I personally think that we should improve the stable addresses. And for
my client node, I'd use RFC 4941, too.

Improving the stable addresses help both the guys that do rfc4941, *and*
the guys that don't.

>>> How does your RA "attack" work in practice here?  Do you mean 
>>> issuing a rogue RA for the same prefix?  We should perhaps
>>> assume that robust rogue RA protection is in place, and if not
>>> there are many worse things an attacker can do!
>> 
>> Agreed. I added this attack vector description, since it was 
>> described by Christian Huitema... so I added it for completeness 
>> sake. Should I twek the text? Remove it?
> 

Agreed.

> For each different IID generated.  Currently implementations *might* 
> assume the IID is the same for link-local and global via traditional 
> SLAAC.  RFC4862 notes that you should run DAD on all addresses.

I'd have no problem with adding this. However, isn't it a *requirement*
to do that, already?

>> It has been years since I last checked MIPv6 (and when I did, I 
>> mostly just skimmed through it). So... up to you. :-)
> 
> Well, nor me, but if you run MIPv6 you're by design wanting to be 
> reachable by a persistent address. I guess at the very least you can 
> say your method can apply when forming the Home Address during the 
> initial bootstrap with the Home Agent. And when the host roams and 
> gets a Care-of Address, the IID used to form the CoA at each visited 
> network will be different, and different to the IID used for the
> HoA. This I guess would reduce trackability as you roam, but would be
> good for a MIP guru to comment.

Will try to find one, and ask for input.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 01 Jun 2013 02:23:10 +0200

On 05/28/2013 11:07 PM, Alissa Cooper wrote:
>>> addresses (but that also configure a stable address that never
>>> gets used). This is what would be expected by users that want to
>>> avoid correlation attacks, assuming their admins allow it. In
>>> this case random and random-per-network provide equivalent
>>> protection.
>> 
>> The problem here is that the assumption of "never gets used" is
>> not correct. Or, well, you might argue "is not intentionally used
>> for legitimate purposes".
>> 
> 
> Intentionally used is what I was going for, since some of the
> discussion about the choice of address generation mechanism revolves
> around intention. That is, some implementations/users might choose
> temporary addresses for specific reasons, sys admins might choose to
> disable them for specific reasons, etc.

IMO, there's a big difference between e.g. RFC4941-disabled vs.
RFC4941-not-used (e.g. as a result of default source address selection).
(the same applies to other combinations).

As noted in stable-privacy, an attacker can leverage e.g. the MAC-based
addresses even if RFC4941 are implemented, enabled, and preferred.

>> An attacker can trigger the use of such addresses, e.g., y sending
>> his probe packets to the stable address.
> 
> In the case of a node that only intentionally uses temporary
> addresses, are there other uses you envision of that node's stable
> address besides the attacks in (a) and (b) in the table?

Not sure what you mean.  Attack (c) employs the stable addresses, too.

>>> temporary addresses and only uses them, random and
>>> random-per-network provide the same benefits (rows 5 and 6). I'm
> Not sure what this means -- in terms of the user's intent, I assume
> most users intend to either use a stable address all the time or use
> temporary addresses all the time.

Not necessarily: the policy might be conveyed by the application.

BTW, what's "random"? -- Microsoft approach to stable addresses, or what?

>> (*) Discussion of possible attacks, and what stable privacy
>> addresses do about them (analyzing this for every possible address
>> generation mechanism would be out of scope for this I-D, IMO).
> 
> Agreed. However, even with the appendix, there are still some places
> where the discussion of the threat models in section 1 could be
> clearer, IMO. For example:
> 
> However, even with temporary addresses [RFC4941] in place, preventing
> correlation of activities of a node within a network may be difficult
> (if at all possible) to achieve.  As a trivial example, consider a
> scenario where there is a single node (or a reduced number of nodes)
> connected to a specific network.  An attacker could detect new
> addresses in use at that network, an infer which addresses are being
> employed by which hosts.  This task is made particularly easier by
> the fact that use of "temporary addresses" can be easily inferred
> (since the follow different patterns from that of traditional SLAAC
> addresses), and since they are re-generated periodically (i.e., after
> a specific amount of time has elapsed).

(FWIW, I moved the above text to Appendix B).

> My read of this is that you're talking about either (1) a situation
> where a node has a globally unique prefix,

Not sure what you mean.

> or (2) a situation where a
> small number of nodes share the same prefix and an attacker can
> disambiguate them using some other information about their behavior
> besides their IP addresses. 

Not sure what you mean by "other information"...

> Is that right? If that's the case, isn't
> correlation possible regardless of how the suffix is generated? The
> document seems to imply that nodes with temporary addresses are more
> susceptible to these two situations than nodes that use other address
> generation mechanisms,

No. The document just says that those attacks are still possible with
RFC4941 -- of course, they are possible without RF4941, too.

> when in fact the first situation (globally
> unique prefix) probably affects all nodes equally regardless of
> generation mechanism, and in the second situation the fact that
> temporary addresses refresh frequently might erect a barrier that
> makes correlation more difficult and that would not exist with random
> or random-per-network addresses.

Of course,  if you don't implement RFC5941, you don't even need to
analyze the address changes.

Again: The appendix just highlights attacks still present with RFC4941.
It does not imply that those attacks are not impossible with the
traditional IEEE-based addresses r with the Microsoft approach t stable
addresses-

> On the other hand, in scenarios in which "temporary addresses" are
> employed together with stable addresses such as those based on IEEE 
> Which correlation attack vectors do random-per-network addresses
> mitigate that temporary addresses do not? 

See appendix B of drat-ietf-6man-stable-privacy-addresses.

> In the analysis in column
> (d) of the table, the correlation entries are the same for all of the
> address generation mechanisms in cases where the node intentionally
> uses temporary addresses.

Agreed.

Thanks!

Best regards,