Subject: IID in LL and GUA - draft-ietf-6man-default-iids-09

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 5 Feb 2016 12:12:06 +0100

Hello 6manners,

draft-ietf-6man-default-iids-09 rightfully indicates that the same IID 
should not be used in the LL and GUA addresses of a same interface.  
Because there may be a risk of correlation between addresses by a snooper.

The draft says:
   The negotiated interface identifier is used by the local end of the
   PPP link to autoconfigure an IPv6 link-local unicast address for the
   PPP interface.  However, it SHOULD NOT be assumed that the same
   interface identifier is used in configuring global unicast addresses
   for the PPP interface using IPv6 stateless address autoconfiguration
   [3].

But what does it mean "it SHOULD NOT be assumed"?  Who should not 
assume?  I think the text should rather say: "a same IID should not be 
used for several different scoped addresses of a same interface because 
snoopers may correlated them".

I am asking because I just realized that a cellular ptp link on linux 
3.4 yocto has this risk: it puts the same ppp-negotiated IID on both its 
LL and its GUA (and it adds a 2nd IID to a 2nd GUA - the 'privacy').  I 
guess it is so because the implementer does not understand "it SHOULD 
NOT be assumed"...

Paradoxically that linux _is_ 'privacy' (it has random addresses instead 
of MAC-based addresses) but still has privacy risks (same IID on a GUA 
and its LL).

And what is [3]?  I guess the brackets should be escaped somehow 
otherwise looking at the list of References in this draft there is no [3].

Alex

---

From: [email-masked]
Date: Fri, 5 Feb 2016 12:27:20 +0100

Alex,

> draft-ietf-6man-default-iids-09 rightfully indicates that the same IID should not be used in the LL and GUA addresses of a same interface.  Because there may be a risk of correlation between addresses by a snooper.
> 
> The draft says:
> But what does it mean "it SHOULD NOT be assumed"?  Who should not assume?  I think the text should rather say: "a same IID should not be used for several different scoped addresses of a same interface because snoopers may correlated them".
> 
> I am asking because I just realized that a cellular ptp link on linux 3.4 yocto has this risk: it puts the same ppp-negotiated IID on both its LL and its GUA (and it adds a 2nd IID to a 2nd GUA - the 'privacy').  I guess it is so because the implementer does not understand "it SHOULD NOT be assumed"...
> 
> Paradoxically that linux _is_ 'privacy' (it has random addresses instead of MAC-based addresses) but still has privacy risks (same IID on a GUA and its LL).
> 
> And what is [3]?  I guess the brackets should be escaped somehow otherwise looking at the list of References in this draft there is no [3].

What is the risk of using the same IID for link-local and global addresses?
Typically if you can snoop the link-local address then you're onlink and leak information about all addresses and their correlations anyway.

cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 5 Feb 2016 13:34:24 +0100

> What is the risk of using the same IID for link-local and global addresses?

I think any correlation risk is worth considering.

In the cellular ptp links there are no MAC addresses in MAC headers; so 
the LL addresses provide great opportunity to track devices.  And if the 
device (LL) has the same address as the application (GUA) then one can 
tell which device consulted which website, for example.

On another hand, if the device had a different address than the app, 
then it would be difficult to say what device consulted what website.

> Typically if you can snoop the link-local address then you're onlink and leak information about all addresses and their correlations anyway.

On a wifi link yes you are onlink, but ptp links are more complex.  A 
p2p link like in cellular extends to actually 2 or 3 different links in 
sequence, from UE to GGSN for example.  This makes for as many 
opportunities to snoop the LL and GUA address even though not the 
snooper is not on the same link (i.e. the snooper can be on the Ethernet 
between a GGSN and a eNodeB, or on one of those, and not be on the air 
between UE and eNodeB).

In all cases, 'privacy' addresses (containing random IIDs rather than 
derived from the constant MAC address) are useful _only_ if there are no 
other GUA addresses on the device which can lead to some form of 
correlation.

Because rarely the applications have the ability to select a specific 
address (i.e. rarely an app can decide to use a privacy address rather 
than an address containing a MAC-derived IID).  So the only means to 
offer privacy to apps is the computer to have only one GUA and that GUA 
to contain a randomly defined IID, and different than the IID in the LL 
address.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 5 Feb 2016 13:52:17 +0100

Let me re-phrase shortly: the problem is to consider the issue to be the 
MAC-derived IIDs, whereas that is not the only issue - the linux issue 
is the GUAs derived from LLs not from MAC (even from LLs which are not 
MAC-derived, but ppp-derived), or the IIDs derived from ppp.

I guess a problem statement may make things clearer.  If we had a 
problem statement which said that the problem is IPv6 addresses derived 
from other addresses (e.g. MAC, LL, PPP-IID) then the abstract of this 
draft should say:

> recommends against embedding identifiers isomorhply derived from other addresses, or dictated by other servers,
> in IPv6 Interface Identifiers.

rather than:
> recommends against embedding link-layer addresses in IPv6 Interface
>    Identifiers.

(the interface ID negotiated during the ppp phase is _not_ a link layer 
address;  it is not used like a MAC address in MAC headers, it does not 
address anything; it is an interface ID dictated by the server to the 
client for use in the addresses, optionally 'negotiated' but never seen 
such a negotiation taking place).

Alex

Le 05/02/2016 13:34, Alexandre Petrescu a écrit :
>>> draft-ietf-6man-default-iids-09 rightfully indicates that the same
>>> IID should not be used in the LL and GUA addresses of a same
>>> interface.  Because there may be a risk of correlation between
>>> addresses by a snooper.
>>>
>>> The draft says:
>>> assume?  I think the text should rather say: "a same IID should not
>>> be used for several different scoped addresses of a same interface
>>> because snoopers may correlated them".
>>>
>>> 3.4 yocto has this risk: it puts the same ppp-negotiated IID on both
>>> its LL and its GUA (and it adds a 2nd IID to a 2nd GUA - the
>>> 'privacy').  I guess it is so because the implementer does not
>>> understand "it SHOULD NOT be assumed"...
>>>
>>> Paradoxically that linux _is_ 'privacy' (it has random addresses
>>> instead of MAC-based addresses) but still has privacy risks (same IID
>>> on a GUA and its LL).
>>>
>> Typically if you can snoop the link-local address then you're onlink
>> and leak information about all addresses and their correlations anyway.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 5 Feb 2016 13:25:04 -0300

Hi, ALex,

> snoopers may correlated them".

You're right. Actually, I'd remove this sentence altogether:
"  However, it SHOULD NOT be assumed that the same
   interface identifier is used in configuring global unicast addresses
   for the PPP interface using IPv6 stateless address autoconfiguration
   [3]."

since RFC7217 takes care of this. Thoughts?

> otherwise looking at the list of References in this draft there is no [3].

That's a reference in the RFC we're quoting.

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 5 Feb 2016 13:28:15 -0300

Ole,

> Typically if you can snoop the link-local address then you're onlink and leak information about all addresses and their correlations anyway.

We discussed this one a hundred times now (including for RFC7217). The
risk is that at times such addressess can leak, without the need of the
attacker being pesent on the local link.

e.g., your MTA is on the local-link, and you end up connecting to it
with a LL, which then appears in the email headers. (and there are a
bunch of other possible reasons for that to happen).

Be proactive. MAC addresses in the IID are wrong. Putting them there is
just waiting for trouble.

Thanks,

---

From: [email-masked]
Date: Fri, 5 Feb 2016 19:07:04 +0100

Fernando,

[...]

> just waiting for trouble.

I didn't say the LL was based on a MAC.
my question was if there was any issue with re-using the IID from the link-local in the GUA. assume the link-local is generated f.ex with 7217.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 5 Feb 2016 15:20:43 -0300

> my question was if there was any issue with re-using the IID from the link-local in the GUA. assume the link-local is generated f.ex with 7217.

Oops, my apologies. My answer would be "It unnecessarily enables
correlation of the activities that you carry between the two addresses".

i.e., by simply inspecting the IID I could easily tell that the
activities carried out with one address were performed by the same node
that employed the other address.

My take here is, again: be proactive. If there's no requirement (and
there isn't) for the two IIDs to be the same, then make them different,
and fail on the safe side.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Feb 2016 09:01:33 +1300

> and fail on the safe side.

But Ole's point was that any observer who sees a LL packet is on-link and
can therefore see the MAC address anyway; an observer who can see MAC addresses
can just laugh at RFC 7217 or RFC 4941.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 5 Feb 2016 17:26:15 -0300

On 02/05/2016 05:01 PM, Brian E Carpenter wrote:
> But Ole's point was that any observer who sees a LL packet is on-link 

That assumption is not correct. You may see a LL because it leaked out
somehow (e.g., you connected to your local MTA using LL, and then the
address got stamped in the email headers).

> and

An observer that sees a MAC address can laugh at 7217 or 4941 for the
purpose of host tracking if the attacer is always on-link. At which
point, you could also argue that the attacker is also able to sniff
traffic...  At which point, mitigating the problem in a comprehensive
manner becomes rather complex. (I'm not saying "impossible", nor am I
saying that you don't want to do that).

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Feb 2016 11:17:49 +1300

> address got stamped in the email headers).

I've certainly seen RFC1918 addresses that way, but I don't recall
seeing IPv6 LL. However, you're correct, it could happen. So I'm certainly
not opposed to recommending a different IID for LL. But we'd better be
sure that there aren't any unintended side-effects, since this would change
20 years of IPv6 practice.

> saying that you don't want to do that).

It definitely takes you out of scope for this draft ;-)

    Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 6 Feb 2016 10:00:42 +1100

>>>> On 02/05/2016 03:07 PM, [email-masked] wrote:

<snip>

> 20 years of IPv6 practice.

My general concern in this area is that attacker access to many links
has become easier, because many of the links are now wireless rather
than wired.

Public wifi networks "protected" by captive portals are now switching
off all of the Wifi security, including WEP, so they're Privacy isn't
even Wired Equivalent, making it easy to attach and capture much of
the traffic without anybody noticing.

Bluetooth 'links' are in general also another example of links that
are easy to collect device details from, using tools such as this one,

https://play.google.com/store/apps/details?id=com.bluemotionlabs.bluescan

that not only record bluetooth device MAC addresses, but also GPS
co-ordinates, and by default uploads them to the earthping.com
website. (Run it while you visit a cafe or shopping centre, it is
somewhat surprising how many bluetooth devices are out there and
announcing themselves - plenty of fitness trackers and phones, what is
surprising is that my local cafe's Smart TV is bluetooth enabled for
some reason or another.)

So I think it is worth starting to rely less on what was the inherent
security of a link, and to treat them as equivalent to "multi-link" or
global threats. That's why I think LLs having different IIDs to any of
the other prefixes on the link is a good idea, and also, ideally, LL
IIDs should be different on different links (to stop LL IIDs being
used to build a similar database to the earthping.com one across, for
example, visits to Internet cafe/hotel/conference networks.)

Regards,
Mark.

---

From: Tim Chown <[email-masked]>
Date: Sun, 7 Feb 2016 16:59:56 +0000

> can just laugh at RFC 7217 or RFC 4941.

Well, except that the device might be varying its MAC address as well.

I thought RFC7217 states that a device is expected to have a different IID for 
each prefix on an interface. (Though whether there’s a NetworkID available to
seed a different LL IID per visited network is another question, else the device
presumably has the same LL IID as it moves?)

There’s definitely value in avoiding correlation. If there’s an equal cost either 
way, why allow such potential?

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 8 Feb 2016 07:47:57 +1300

> way, why allow such potential?

Extra code? But my real concern is that there might be unintended side effects,
because the interface identifier will no longer identify an interface.

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Feb 2016 09:41:48 +0100

> since RFC7217 takes care of this. Thoughts?

I think it is good.  Better would be "the same IID present in LL SHOULD 
NOT be used in configuring GUA (or ULA) for the ppp interface".

'SHOULD NOT be assumed' is unclear.

> That's a reference in the RFC we're quoting.

Ok, I understand.  So this RFC-to-be is less self-contained - it must be 
read together with the referred RFCs.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 8 Feb 2016 09:46:28 +0100

Le 05/02/2016 21:01, Brian E Carpenter a écrit :
> can therefore see the MAC address anyway;

Links which share same non-MAC IID for LL and GUA are necessarily ppp 
links (this sharing does not happen on wifi links for example).

On these ppp links there are no MAC addresses and no MAC headers, so the 
observer can't see them.

> an observer who can see MAC addresses

There are observers and observers.  We need to protected against 
unlawful observers.  In ppp links the lawful observers (lawful 
interception) have access to the IIDs.  The unlawful observers dont.

The lawful observers dont need to make correlations because they have them.

Alex

---

From: Mark Smith <[email-masked]>
Date: Mon, 8 Feb 2016 19:57:47 +1100

>>>> my question was if there was any issue with re-using the IID from the
link-local in the GUA. assume the link-local is generated f.ex with 7217.
observer can't see them.
> There are observers and observers.  We need to protected against unlawful
observers.  In ppp links the lawful observers (lawful interception) have
access to the IIDs.  The unlawful observers dont.

So I don't think there are any technical constraints preventing running PPP
over PPPoE over Wi-Fi or some other wireless link prone to offlink
capturing. (e.g. an ISP might backhaul traffic via a wireless link, and use
PPPoE over it to distinguish users, rather than put a NAS/BRAS/BNG at the
remote site (perhaps a mine site, providing after hours Internet access to
onsite workers.)

IOW, PPP framing doesn't ensure the underlying link is a physical one with
only two ends.

---

From: Tim Chown <[email-masked]>
Date: Mon, 8 Feb 2016 09:56:31 +0000

> On 7 Feb 2016, at 18:47, Brian E Carpenter <[email-masked]> wrote:
> 

Fair enough, and there are some notes on this in RFC 4914 with a section 
on the possible implications of varying IIDs. 

But RFC 7217, and draft-ietf-6man-default-iids-09 say different. Perhaps 
you should look at capturing these concerns in that draft, so such side effects
are noted.

One premise within that draft is:
“given two addresses, it must be difficult for an outside entity
 to tell whether the addresses have been generated by the same host."
which further reinforces the different IIDs for GUAs (multiple, if the device
is multihomed) and LLs.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Mon, 8 Feb 2016 22:10:56 -0300

On 02/07/2016 03:47 PM, Brian E Carpenter wrote:
[....]
> because the interface identifier will no longer identify an interface.

Well, the IID only really identifies an interface for a given prefix.
For instance, DAD is done only for such given prefix.

And there is no requirement whatsoever that the IID for one prefix is
the same as that used for the same interface for a different autoconf
prefix.

Thanks!

Cheers,

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Feb 2016 07:09:09 +0100

> For instance, DAD is done only for such given prefix.

I agree.  It's an interface identifier but only within a prefix.

The IID alone (w/o prefix) is not used anywhere AFAIK.  In dhhcpv6.conf, 
in neigh cache, etc it's the MAC address being used.

Alex

---

From: Mark Smith <[email-masked]>
Date: Tue, 9 Feb 2016 17:33:21 +1100

and
> I agree.  It's an interface identifier but only within a prefix.

And RFC4291 even specifically says that a node may use the same IIDs on
different interfaces, and that they can be different for different prefixes
on the same link, which I think  shows their significance is limited to
within a prefix.

https://tools.ietf.org/html/rfc4291#section-2.5.1

---

From: Tim Chown <[email-masked]>
Date: Tue, 9 Feb 2016 10:29:47 +0000

> On 9 Feb 2016, at 06:33, Mark Smith <[email-masked]> wrote:
> On 9 Feb 2016 17:09, "Alexandre Petrescu" <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >
> >
> And RFC4291 even specifically says that a node may use the same IIDs on different interfaces, and that they can be different for different prefixes on the same link, which I think  shows their significance is limited to within a prefix.
> 
> https://tools.ietf.org/html/rfc4291#section-2.5.1 <https://tools.ietf.org/html/rfc4291#section-2.5.1>Indeed. So long as they are unique within that subnet prefix, as stated.

The interesting question with LL IIDs is whether they should change per visited network. My understanding of RFC 7217 is that the LL IID will remain the same unless the visited network presents a Network ID to be used in the generation of the IID, and even then if the ID is the SSID then it may well be the same SSID name on many visited networks.  Or might the MAC address be used for Net_Iface allowing the LL IID to change when the MAC address is changed (given there’s recent movement towards dynamic/temporary MAC addresses).

I don’t think it’s good to assume that using the same IID for GUAs and LLs is OK. I do support documenting potential side effects in the currently active IIDs draft.

Tim
> > The IID alone (w/o prefix) is not used anywhere AFAIK.  In dhhcpv6.conf, in neigh cache, etc it's the MAC address being used.
> >
> > Alex
> >
> >
> >>
> > [email-masked] <mailto:[email-masked]>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 9 Feb 2016 08:05:16 -0300

On 02/07/2016 01:59 PM, Tim Chown wrote:
[....]
> each prefix on an interface.

Yes.

> (Though whether there’s a NetworkID available to

The NetworkID parameter was made optional mostly because e.g. in wired
internet such identifier might not be easily available (at least as
easily as e.g. the SSID of the net). But yes, I would expect the LL
addresses to have a different IID per network.

> way, why allow such potential?

That's my take as well.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 9 Feb 2016 08:06:41 -0300

> because the interface identifier will no longer identify an interface.

Not really. RFC7217 automagically achieves that.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 9 Feb 2016 08:14:52 -0300

On 02/08/2016 05:41 AM, Alexandre Petrescu wrote:
[....]
> 'SHOULD NOT be assumed' is unclear.

But this would mean that the IPv6-over-PPP document would have extra
requirements for ID generation, and that wouldn't be a good thing.
Removing the offending the solves the problem, because RFC7217 simply
will not use the same IID for GUAs and LLs.

> read together with the referred RFCs.

Not really. The section about "changes to RFCs" is, IMO, mostly a list
of patches that must be applied to RFCs when/if they are revised.

The self-contained part of the document essentially is "whenever you
need to generate IIDs, use RFC7217".

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 9 Feb 2016 08:34:50 -0300

> on the possible implications of varying IIDs. 

FWIW, the concerns in RFC4941 are rather about the temporary nature of
the IIDs rather than as a result of different IIDs in e.g. LLS vs GUAs...

> which further reinforces the different IIDs for GUAs (multiple, if the device

Exactly.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 9 Feb 2016 08:39:13 -0300

Hi, Erik,

On 02/08/2016 07:17 AM, Erik Kline wrote:
> One drawback of increasing the number of IIDs in use on the link is it
> increases the number of solicited node multicast groups to which the
> device must subscribe.  On shared /64 links this is probably
> unavoidable.

Yes. However, this hen compared to the "10 temp addresses per prefix at
a time" is a piece of cake (i.e., one group for LL and one grop for GUA).

> (Obviously, trying to get all your "random" IIDs into the same or a
> few /104s would be rather lame.  :-)
> 
> I'm not sure I see any real problem with having the same LL and GUA
> IID, even if they do leak.
> 
>     [1] if they're randomized at network attach (and I'm not on the
> link too long) then who cares
> 
>     [2] if they're "stable" 7217-style then they're "permanently
> leaked" by design and who cares

It's not necessarily a problem.

However, it would actually take special code to make the two IIDs the
same (FC7217, by default, would result in different IIDs for each). And,
being proactive, you fail on the safe side, even if there's no evident
drawback

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Feb 2016 07:53:36 +1300

> Not really. RFC7217 automagically achieves that.

Let me be even clearer about my concern; then I will shut up:

I fully agree that from a privacy point of view, it is better to use
a different IID for link-local and for each GUA prefix (including each
ULA prefix). I'm not aware of anywhere in the IETF standards that this
will lead to a problem. However, I am concerned that in some IPv6 networks,
especially networks running with only one GUA prefix (which is most of
them) there are operational practices and/or locally written scripts
that *assume* the same IID is used for all prefixes on a given interface.
After all, that has been the case for all IPv6 stacks for many years.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Tue, 9 Feb 2016 19:16:27 +0000

> On 9 Feb 2016, at 18:53, Brian E Carpenter <[email-masked]> wrote:
> 

But those scripts will already fail if correlating privacy addresses with others.

It would be interesting to ask on a v6 operators list whether anyone really does
make that assumption in scripts, whether their own or in open source packages.
If there are any, they’ll probably disable 7217 anyway to have MAC-based 
addresses to correlate IPs and MACs (however good an idea that is).

Tim

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 10 Feb 2016 13:47:27 -0600

> But those scripts will already fail if correlating privacy addresses with others.

I was going to echo this as well, but you beat me to it.

Dale