Subject: Status of Privacy Extensions for Stateless Address Autoconfiguration in IPv6

From: Bob Hinden <[email-masked]>
Date: Wed, 1 Apr 2020 14:01:13 -0700

Based on the discussion at yesterday’s interim 6man meeting, the chairs believe that <draft-ietf-6man-rfc4941bis> is ready to advance to the IESG.

We wanted to verify this with the working group.   Please let us know if you have any significant issues that need to be resolved that haven’t been discussed earlier.  We plan to advance it later this week otherwise.

Bob & Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 2 Apr 2020 10:55:50 +1300

I wasn't in the meeting due to time zone, but I agree that this is ready to go.

Regards
   Brian

On 02-Apr-20 10:01, Bob Hinden wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Apr 2020 12:08:32 +0200

Hi,

draft says:
> This document describes an extension that causes nodes to generate
> global scope addresses with randomized interface identifiers that
> change over time.

It is not sufficient to use randomized IIDs to offer a sense of privacy.

The network prefix might need to not be fixed either.

It is not only about changing the IID over time, it is also the fact 
that the length of that IID is likely to be fixed forever.

With these two things at hand: fixed length of IID, and single prefix 
advertised by the router for SLAAC, an adversary might do attacks on 
privacy, despite the IID changing over time.

This is particularly the case in cellular networks: a single prefix is 
advertised to an UE, of fixed length.  And, it is here that IID changes 
often in implementations.  But it is still here that privacy might be at 
risk, more than in other places like wifi networks.

Alex, LF/HF 1

Le 01/04/2020 à 23:55, Brian E Carpenter a écrit :
> Regards Brian
>> Based on the discussion at yesterday’s interim 6man meeting, the
>> chairs believe that <draft-ietf-6man-rfc4941bis> is ready to
>> advance to the IESG.
>> 
>> We wanted to verify this with the working group.   Please let us
>> know if you have any significant issues that need to be resolved
>> that haven’t been discussed earlier.  We plan to advance it later
>> this week otherwise.
>> 
>> Bob & Ole
>> 
>> 
>> 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 08:36:37 -0300

Hi, Alexandre,

> privacy, despite the IID changing over time.

This was already discussed on the mailing-list, is noted in the draft, 
and as mentioned during the interim call, I noted that even the title 
was changed to focus on what the mechanism provides.

Unless there's anything new to add, I don't think we need to re-hash 
previous discussions.

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Apr 2020 14:23:17 +0200

LF/HF

> This was already discussed on the mailing-list, is noted in the draft, 
Do you mean this in the draft?
> If the network contains a very small number
>    of nodes, say, just one, changing just the interface identifier will
>    not enhance privacy, since the prefix serves as a constant
>    identifier.

Would it be possible to specifically say this:
"not only the the contents of a prefix is constant, but its length is a
  constant as well."

Would it be possible to suggest a requirement like this:
"It is a requirement that the network accepts a prefix dictated by the
  UE"

Alex, LF/HF 1

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Apr 2020 14:25:51 +0200

would it it be possible to specify this:
> However, the method discussed in
>           this document could be employed for generating Interface IDs
>           of any arbitrary length, albeit at the expense of reduced
>           entropy (when employing Interface IDs smaller than 64 bits) or enhanced entropy (when IID len longer than 64)

(note 'IID longer than 64')

Alex, LF/HF 1

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Apr 2020 14:30:43 +0200

Would it be possible to modify this:
>   _Some of_ The privacy implications of the IID length are discussed in
>           [RFC7421].

remark stressed _some_ implications.

That RC7421 does not discuss the privacy implications of using IID of 
length longer than 64, just shorter.

The privacy implications of using a longer than 64 IID length are 
positive: it is harder to guess.

The privacy implications of using an arbitrary length IID are positive: 
the attacker can not assume a fixed boundary.  On the contrary, current 
specs mandate a fixed IID length.

These two points are not mentioned in RFC7421.  Hence it's just _some_ 
privacy implications of the IID length that are discussed in RFC7421.

Alex, LF/HF 1

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 09:35:45 -0300

> Do you mean this in the draft?

Yes.

> "It is a requirement that the network accepts a prefix dictated by the

Not sure what you mean. At the time of this writing, SLAAC mandates 
/64s. This document has not say about the prefix length.

Am I missing something?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 09:39:27 -0300

On 2/4/20 09:25, Alexandre Petrescu wrote:
>>           entropy (when employing Interface IDs smaller than 64 bits) 
>> or enhanced entropy (when IID len longer than 64)
> 

Not sure what you mean.
1) That's of course implied
2) 2**64 is enough entropy for this kind of thing. Why would anyone do 
that??

I miss the point you are trying to make...

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Apr 2020 14:49:43 +0200

Le 02/04/2020 à 14:35, Fernando Gont a écrit :
>>>>> This document describes an extension that causes nodes to
>>>>> generate global scope addresses with randomized interface
>>>>> identifiers that change over time.
>>>> 
>>>> It is not only about changing the IID over time, it is also the
>>>> fact that the length of that IID is likely to be fixed
>>>> forever.
>>>> 
>>>> With these two things at hand: fixed length of IID, and single
>>>>  prefix advertised by the router for SLAAC, an adversary might
>>>> do attacks on privacy, despite the IID changing over time.
>>> 
>>> If the network contains a very small number of nodes, say, just
>>> one, changing just the interface identifier will not enhance
>>> privacy, since the prefix serves as a constant identifier.
>> 
>> Would it be possible to specifically say this: "not only the the
>> contents of a prefix is constant, but its length is a constant as
>> well."
>> 
[...]
> /64s. This document has not say about the prefix length.  Am I
> missing something?

We work on a draft for SLAAC with variable length (not only 64).  You
dont miss anything.  It is an individual proposal.  We have not posted
the draft to IETF because various deadline problems, but it's there on 
github.

The Internet Draft rfc4941bis does say 'length' at several places.

>> Would it be possible to suggest a requirement like this: "It is a
>> requirement that the network accepts a prefix dictated by the UE"

This ^ has nothing to do with SLAAC and 64.  It is about the network 
accepting or refusing that it is the Host who suggests the prefix, not 
the network.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Apr 2020 14:54:26 +0200

> I miss the point you are trying to make...

At some point you say less than 64 entropy might not be enough, and that 
a limit is not clear.

But similarly, more than 64 entropy might be more than enough - you just 
dont say it.

You say 'it is implied', but there is silence, actually.

There is nothing in I-D RFC4941bis, nor in RFC7421, that talks about IID 
length longer than 64.

There is nothing in any RFC that talks about longer than 64 IIDs.  Even 
the RFC that got implemented in OpenBSD and which implements any length 
for IID, does not say 'longer than 64 IID'.

I would like that to be written.

IMHO,

Alex, LF/HF 1

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 10:16:10 -0300

Alexandre,

On 2/4/20 09:54, Alexandre Petrescu wrote:
>>>>           entropy (when employing Interface IDs smaller than 64 
>>>> bits) or enhanced entropy (when IID len longer than 64)
>>>

Nope neither me nor the document says that. The document says the 
obvious: the algorithm does not have any inherent requirement regarding 
the IID length. Of course, if you change the IID length, you change the 
entropy (the search space). (e.g., if you reduced the IID length, the 
entropy would be reduced).

> But similarly, more than 64 entropy might be more than enough - you just 

Let me put it bluntly: even 32 bits would be more than enough for this.

And I don't think this document is the place to discuss IID lengths.

If anything, I'd be okay with removing this text: ", albeit at the 
expense of reduced entropy (when employing Interface IDs smaller than 64 
bits)."

> There is nothing in I-D RFC4941bis, nor in RFC7421, that talks about IID 

1) The current architecture doesn't have such a thing

2) I personally don't think anybody would even think about IIDs longer 
than 64 bits. 64-bit IIDs already waste a big part of the address space.

But, in any case, that's not the topic for this document.

As noted, I'd be okay to remove the text about smaller IIDs, if you prefer.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Apr 2020 15:32:33 +0200

Le 02/04/2020 à 15:16, Fernando Gont a écrit :
>>> 2) 2**64 is enough entropy for this kind of thing. Why would anyone 
>>> do that??
>>>
>> At some point you say less than 64 entropy might not be enough, and 
>> that a limit is not clear.
> 
>> But similarly, more than 64 entropy might be more than enough - you 
>> just dont say it.
> 

Yes, write that down.  I agree with you.  I do not know why not writing 
it down.

> And I don't think this document is the place to discuss IID lengths.

The length of an IID is a privacy issue.

The constant length of IID is mandated by all IPv6-over-foo documents, 
and by many people who are considered to be majority, or rough 
consensus, and by AD, if you wish.

I do not understand why not facing it.

> expense of reduced entropy (when employing Interface IDs smaller than 64 

I do not ask for that.  I do not ask to remove that text.  That text 
makes sense.  It should be enhanced to say that privacy might be 
improved if IID longer than 64.

>> There is nothing in I-D RFC4941bis, nor in RFC7421, that talks about 
>> IID length longer than 64.
> 

All IPv6-over-foo docs request it, and the IPv6 Addr Arch requests it.

We just disagree how to read them.

> than 64 bits. 64-bit IIDs already waste a big part of the address space.

??  No, I dont think so.

I personally think IIDs longer than 64bit are absolutely necessary in 
some contexts.  A SLAAC where a router that advertises a /56 in an RA, 
might need the Host  to form a 72bit IID.

> But, in any case, that's not the topic for this document.

The topic of the document is Privacy in SLAAC.

All the issues I wrote above are privacy issues.

It is a whole system: the 64bit random IID is a bit of privacy but not 
enough.

SEcurity is a chain: the weakest link breaks the entire chain.

Alex

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 10:47:25 -0300

On 2/4/20 10:32, Alexandre Petrescu wrote:
>> obvious: the algorithm does not have any inherent requirement 
>> regarding the IID length. Of course, if you change the IID length, you 
>> change the entropy (the search space). (e.g., if you reduced the IID 
>> length, the entropy would be reduced).
>>
>>

Because this is not a document to discuss IID lengths. The current specs 
mandate /64. If that's changed, such document should do the appropriate 
analysis. There's no reason for this document to do that.

> All IPv6-over-foo docs request it, and the IPv6 Addr Arch requests it.

Exactly. There's no point in getting into a discussion about something 
that's not even allowed in the current specs.

[...]
> might need the Host  to form a 72bit IID.

Write a draft, and propose that change. Until that, this document need 
to stick to existing specs.

Thanks,

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Apr 2020 15:57:32 +0200

Le 02/04/2020 à 15:47, Fernando Gont a écrit :
>>> regarding the IID length. Of course, if you change the IID length, 
>>> you change the entropy (the search space). (e.g., if you reduced the 
>>> IID length, the entropy would be reduced).
>>>
>>>
>> Yes, write that down.  I agree with you.  I do not know why not 
>> writing it down.
> 

True.

It might be this is not a right time to advance this document to IESG.

Maybe address first that IID length in the IPv6 Addr Arch document.

Until then, any privacy work might be irrelevant.

Security is a chain: weakest link breaks it all.

Alex, LF/HF 1

>>> 2) I personally don't think anybody would even think about IIDs 
>>> longer than 64 bits. 64-bit IIDs already waste a big part of the 
>>> address space.
>>
>> ??  No, I dont think so.
>>