"RFC4941bis" and draft-gont-6man-non-stable-iids

[Fernando Gont]

Folks,

Among the list of RFCs to be progressed to full std is/was RFC4941
("Privacy Extensions for Stateless Address Autoconfiguration in IPv6").

As it stands, RFC4941 has a number of issues:

* Using the same IID for multiple prefixes
* Not changing the IID upon "security events" (including e.g., change in
the underlying MAC address)
* Using MD5 as opposed to something better
* Requiring the use of temporary addresses along stable addresses
(preventing use of temporary-only, for nodes that feel like)
* Not treating IIDs as opaque values (see RFC7136) when generating the
randomized IIDs (see step 3 in section 3.2.1 of RFC4941)
* Mandating one specific algorithm, when the same goals/properties can
be achieved with multiple algorithms (see section 4 of
draft-gont-6man-non-stable-iids-01)


Based on the above, I personally don't think that it would make sense to
progress RFC4941 to Internet Standard, but rather think that we should
work on a replacement of it -- our proposal being
draft-gont-6man-non-stable-iids-01.

Thoughts?

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Mark Smith]

+1

On 19 July 2017 at 00:52, Fernando Gont <***@si6networks.com> wrote:
> Folks,
>
> Among the list of RFCs to be progressed to full std is/was RFC4941
> ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6").
>
> As it stands, RFC4941 has a number of issues:
>
> * Using the same IID for multiple prefixes
> * Not changing the IID upon "security events" (including e.g., change in
> the underlying MAC address)
> * Using MD5 as opposed to something better
> * Requiring the use of temporary addresses along stable addresses
> (preventing use of temporary-only, for nodes that feel like)
> * Not treating IIDs as opaque values (see RFC7136) when generating the
> randomized IIDs (see step 3 in section 3.2.1 of RFC4941)
> * Mandating one specific algorithm, when the same goals/properties can
> be achieved with multiple algorithms (see section 4 of
> draft-gont-6man-non-stable-iids-01)
>
>
> Based on the above, I personally don't think that it would make sense to
> progress RFC4941 to Internet Standard, but rather think that we should
> work on a replacement of it -- our proposal being
> draft-gont-6man-non-stable-iids-01.
>
> Thoughts?
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: ***@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ***@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

[Tim Chown]

> On 18 Jul 2017, at 15:52, Fernando Gont <***@si6networks.com> wrote:
>
> Folks,
>
> Among the list of RFCs to be progressed to full std is/was RFC4941
> ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6").
>
> As it stands, RFC4941 has a number of issues:
>
> * Using the same IID for multiple prefixes
> * Not changing the IID upon "security events" (including e.g., change in
> the underlying MAC address)
> * Using MD5 as opposed to something better
> * Requiring the use of temporary addresses along stable addresses
> (preventing use of temporary-only, for nodes that feel like)
> * Not treating IIDs as opaque values (see RFC7136) when generating the
> randomized IIDs (see step 3 in section 3.2.1 of RFC4941)
> * Mandating one specific algorithm, when the same goals/properties can
> be achieved with multiple algorithms (see section 4 of
> draft-gont-6man-non-stable-iids-01)
>
>
> Based on the above, I personally don't think that it would make sense to
> progress RFC4941 to Internet Standard, but rather think that we should
> work on a replacement of it -- our proposal being
> draft-gont-6man-non-stable-iids-01.
>
> Thoughts?

Certainly any update on 4941 needs to be done in the light of a few deficiencies that have emerged over the years, and the publication of RFC7217.

I think it’s still possible to do a -bis off 4941.

Tim

[Fernando Gont]

On 07/19/2017 01:58 PM, Tim Chown wrote:
>> On 18 Jul 2017, at 15:52, Fernando Gont <***@si6networks.com>
>> wrote:
>>
>> Folks,
>>
>> Among the list of RFCs to be progressed to full std is/was RFC4941
>> ("Privacy Extensions for Stateless Address Autoconfiguration in
>> IPv6").
>>
>> As it stands, RFC4941 has a number of issues:
>>
>> * Using the same IID for multiple prefixes * Not changing the IID
>> upon "security events" (including e.g., change in the underlying
>> MAC address) * Using MD5 as opposed to something better * Requiring
>> the use of temporary addresses along stable addresses (preventing
>> use of temporary-only, for nodes that feel like) * Not treating
>> IIDs as opaque values (see RFC7136) when generating the randomized
>> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one
>> specific algorithm, when the same goals/properties can be achieved
>> with multiple algorithms (see section 4 of
>> draft-gont-6man-non-stable-iids-01)
>>
>>
>> Based on the above, I personally don't think that it would make
>> sense to progress RFC4941 to Internet Standard, but rather think
>> that we should work on a replacement of it -- our proposal being
>> draft-gont-6man-non-stable-iids-01.
>>
>> Thoughts?
>
> Certainly any update on 4941 needs to be done in the light of a few
> deficiencies that have emerged over the years, and the publication of
> RFC7217.
>
> I think it’s still possible to do a -bis off 4941.

My questions would be:

1) Can you actually address the aforementioned deficiencies without
significant changes to RFC4941? -- It would seem to me that in order to
address them, rfc4941bis would not be a bis document anymore.

2) If you were to address such deficiencies, could the bis document be
progressed to Internet Standard? -- My assessment of this question is: No.


If RFC4941 would take significant work, and the end result would
actually be significantly different from what's in RFC4941, then I'm not
sure that'd be different than starting from the I-D we already have...

Thanks!

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Tim Chown]

> On 19 Jul 2017, at 13:57, Fernando Gont <***@si6networks.com> wrote:
>
> On 07/19/2017 01:58 PM, Tim Chown wrote:
>>> On 18 Jul 2017, at 15:52, Fernando Gont <***@si6networks.com>
>>> wrote:
>>>
>>> Folks,
>>>
>>> Among the list of RFCs to be progressed to full std is/was RFC4941
>>> ("Privacy Extensions for Stateless Address Autoconfiguration in
>>> IPv6").
>>>
>>> As it stands, RFC4941 has a number of issues:
>>>
>>> * Using the same IID for multiple prefixes * Not changing the IID
>>> upon "security events" (including e.g., change in the underlying
>>> MAC address) * Using MD5 as opposed to something better * Requiring
>>> the use of temporary addresses along stable addresses (preventing
>>> use of temporary-only, for nodes that feel like) * Not treating
>>> IIDs as opaque values (see RFC7136) when generating the randomized
>>> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one
>>> specific algorithm, when the same goals/properties can be achieved
>>> with multiple algorithms (see section 4 of
>>> draft-gont-6man-non-stable-iids-01)
>>>
>>>
>>> Based on the above, I personally don't think that it would make
>>> sense to progress RFC4941 to Internet Standard, but rather think
>>> that we should work on a replacement of it -- our proposal being
>>> draft-gont-6man-non-stable-iids-01.
>>>
>>> Thoughts?
>>
>> Certainly any update on 4941 needs to be done in the light of a few
>> deficiencies that have emerged over the years, and the publication of
>> RFC7217.
>>
>> I think it’s still possible to do a -bis off 4941.
>
> My questions would be:
>
> 1) Can you actually address the aforementioned deficiencies without
> significant changes to RFC4941? -- It would seem to me that in order to
> address them, rfc4941bis would not be a bis document anymore.
>
> 2) If you were to address such deficiencies, could the bis document be
> progressed to Internet Standard? -- My assessment of this question is: No.
>
> If RFC4941 would take significant work, and the end result would
> actually be significantly different from what's in RFC4941, then I'm not
> sure that'd be different than starting from the I-D we already have...

Just to be clear, I like the material in your new draft.

That said, it seems you could do a similar style of update from 3041 to 4941, with a similar structure; the content is there in your draft, it “just" needs to be merged in.

That would mean obsoleting 4941, just as 4941 obsoleted 3041. So you would include the details in 4941 that would carry forward.

Tim

[Suresh Krishnan]

Hi Tim,

> On Jul 19, 2017, at 6:00 PM, Tim Chown <***@jisc.ac.uk> wrote:
>
>> On 19 Jul 2017, at 13:57, Fernando Gont <***@si6networks.com> wrote:
>>
>> On 07/19/2017 01:58 PM, Tim Chown wrote:
>>>> On 18 Jul 2017, at 15:52, Fernando Gont <***@si6networks.com>
>>>> wrote:
>>>>
>>>> Folks,
>>>>
>>>> Among the list of RFCs to be progressed to full std is/was RFC4941
>>>> ("Privacy Extensions for Stateless Address Autoconfiguration in
>>>> IPv6").
>>>>
>>>> As it stands, RFC4941 has a number of issues:
>>>>
>>>> * Using the same IID for multiple prefixes * Not changing the IID
>>>> upon "security events" (including e.g., change in the underlying
>>>> MAC address) * Using MD5 as opposed to something better * Requiring
>>>> the use of temporary addresses along stable addresses (preventing
>>>> use of temporary-only, for nodes that feel like) * Not treating
>>>> IIDs as opaque values (see RFC7136) when generating the randomized
>>>> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one
>>>> specific algorithm, when the same goals/properties can be achieved
>>>> with multiple algorithms (see section 4 of
>>>> draft-gont-6man-non-stable-iids-01)
>>>>
>>>>
>>>> Based on the above, I personally don't think that it would make
>>>> sense to progress RFC4941 to Internet Standard, but rather think
>>>> that we should work on a replacement of it -- our proposal being
>>>> draft-gont-6man-non-stable-iids-01.
>>>>
>>>> Thoughts?
>>>
>>> Certainly any update on 4941 needs to be done in the light of a few
>>> deficiencies that have emerged over the years, and the publication of
>>> RFC7217.
>>>
>>> I think it’s still possible to do a -bis off 4941.
>>
>> My questions would be:
>>
>> 1) Can you actually address the aforementioned deficiencies without
>> significant changes to RFC4941? -- It would seem to me that in order to
>> address them, rfc4941bis would not be a bis document anymore.
>>
>> 2) If you were to address such deficiencies, could the bis document be
>> progressed to Internet Standard? -- My assessment of this question is: No.
>>
>> If RFC4941 would take significant work, and the end result would
>> actually be significantly different from what's in RFC4941, then I'm not
>> sure that'd be different than starting from the I-D we already have...
>
> Just to be clear, I like the material in your new draft.
>
> That said, it seems you could do a similar style of update from 3041 to 4941, with a similar structure; the content is there in your draft, it “just" needs to be merged in.
>
> That would mean obsoleting 4941, just as 4941 obsoleted 3041. So you would include the details in 4941 that would carry forward.

<AD hat off>. I agree. If we are planning a drop in replacement to RFC4941 creating a bis document from there is the right thing to do.

Thanks
Suresh

[Fernando Gont]

On 07/20/2017 11:21 AM, Suresh Krishnan wrote:
> Hi Tim,
>
>> On Jul 19, 2017, at 6:00 PM, Tim Chown <***@jisc.ac.uk
>> <mailto:***@jisc.ac.uk>> wrote:
>>
>>> On 19 Jul 2017, at 13:57, Fernando Gont <***@si6networks.com
>>> <mailto:***@si6networks.com>> wrote:
>>>
>>> On 07/19/2017 01:58 PM, Tim Chown wrote:
>>>>> On 18 Jul 2017, at 15:52, Fernando Gont <***@si6networks.com
>>>>> <mailto:***@si6networks.com>>
>>>>> wrote:
>>>>>
>>>>> Folks,
>>>>>
>>>>> Among the list of RFCs to be progressed to full std is/was RFC4941
>>>>> ("Privacy Extensions for Stateless Address Autoconfiguration in
>>>>> IPv6").
>>>>>
>>>>> As it stands, RFC4941 has a number of issues:
>>>>>
>>>>> * Using the same IID for multiple prefixes * Not changing the IID
>>>>> upon "security events" (including e.g., change in the underlying
>>>>> MAC address) * Using MD5 as opposed to something better * Requiring
>>>>> the use of temporary addresses along stable addresses (preventing
>>>>> use of temporary-only, for nodes that feel like) * Not treating
>>>>> IIDs as opaque values (see RFC7136) when generating the randomized
>>>>> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one
>>>>> specific algorithm, when the same goals/properties can be achieved
>>>>> with multiple algorithms (see section 4 of
>>>>> draft-gont-6man-non-stable-iids-01)
>>>>>
>>>>>
>>>>> Based on the above, I personally don't think that it would make
>>>>> sense to progress RFC4941 to Internet Standard, but rather think
>>>>> that we should work on a replacement of it -- our proposal being
>>>>> draft-gont-6man-non-stable-iids-01.
>>>>>
>>>>> Thoughts?
>>>>
>>>> Certainly any update on 4941 needs to be done in the light of a few
>>>> deficiencies that have emerged over the years, and the publication of
>>>> RFC7217.
>>>>
>>>> I think it’s still possible to do a -bis off 4941.
>>>
>>> My questions would be:
>>>
>>> 1) Can you actually address the aforementioned deficiencies without
>>> significant changes to RFC4941? -- It would seem to me that in order to
>>> address them, rfc4941bis would not be a bis document anymore.
>>>
>>> 2) If you were to address such deficiencies, could the bis document be
>>> progressed to Internet Standard? -- My assessment of this question
>>> is: No.
>>>
>>> If RFC4941 would take significant work, and the end result would
>>> actually be significantly different from what's in RFC4941, then I'm not
>>> sure that'd be different than starting from the I-D we already have...
>>
>> Just to be clear, I like the material in your new draft.
>>
>> That said, it seems you could do a similar style of update from 3041
>> to 4941, with a similar structure; the content is there in your draft,
>> it “just" needs to be merged in.
>>
>> That would mean obsoleting 4941, just as 4941 obsoleted 3041. So you
>> would include the details in 4941 that would carry forward.
>
> <AD hat off>. I agree. If we are planning a drop in replacement to
> RFC4941 creating a bis document from there is the right thing to do.

Can you explain your rationale? (along with answering the two questions
I posed to Tim).

RFC4941 can be summarized as consisting of two parts:

1) A discussion of privacy implications of Identifiers, and of IIDs in
particular

2) Specification of an algorithm to generate the IID


"1)" was much needed when RFC3041 was published, and then carried to
RFC4941 (when it was probably still needed). Nowadays, the security and
privacy properties of IPv6 addresses are discussed more thoroughly (and
in more dimensions) in RFC7721. And the discussion of identifiers in
documents such as RFC6973 and draft-gont-predictable-numeric-ids
(besides the fact that one can always refer back to RFC3041 or even
RFC4941 for such discussion, in the same way we referenced RFC3041 in
RFC7721).

When it comes to "2)", if you really want to address the issues found in
RFC4941, essentially you need to replace the algorithm with something
else. One may tweak a few things here and there (e.g., the update we
propose in our I-D), but still there are drawbacks in RFC4941 that
cannot be addressed without fundamentally changing the algorithm (for
instance, RFC4941 has notable drawbacks when compared to simply
generating the IID as a random number that is not tied to previously
selected IIDs). If one were to do rfc4941bis, such document could not be
progressed to STD. And since there are better and/or alternative
approaches for generating temporary addresses, I'm not sure what would
be the benefit here.

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Tim Chown]

> On 20 Jul 2017, at 12:03, Fernando Gont <***@si6networks.com> wrote:
>
> On 07/20/2017 11:21 AM, Suresh Krishnan wrote:
>> Hi Tim,
>>
>>> On Jul 19, 2017, at 6:00 PM, Tim Chown <***@jisc.ac.uk
>>> <mailto:***@jisc.ac.uk>> wrote:
>>>
>>>> On 19 Jul 2017, at 13:57, Fernando Gont <***@si6networks.com
>>>> <mailto:***@si6networks.com>> wrote:
>>>>
>>>> On 07/19/2017 01:58 PM, Tim Chown wrote:
>>>>>> On 18 Jul 2017, at 15:52, Fernando Gont <***@si6networks.com
>>>>>> <mailto:***@si6networks.com>>
>>>>>> wrote:
>>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> Among the list of RFCs to be progressed to full std is/was RFC4941
>>>>>> ("Privacy Extensions for Stateless Address Autoconfiguration in
>>>>>> IPv6").
>>>>>>
>>>>>> As it stands, RFC4941 has a number of issues:
>>>>>>
>>>>>> * Using the same IID for multiple prefixes * Not changing the IID
>>>>>> upon "security events" (including e.g., change in the underlying
>>>>>> MAC address) * Using MD5 as opposed to something better * Requiring
>>>>>> the use of temporary addresses along stable addresses (preventing
>>>>>> use of temporary-only, for nodes that feel like) * Not treating
>>>>>> IIDs as opaque values (see RFC7136) when generating the randomized
>>>>>> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one
>>>>>> specific algorithm, when the same goals/properties can be achieved
>>>>>> with multiple algorithms (see section 4 of
>>>>>> draft-gont-6man-non-stable-iids-01)
>>>>>>
>>>>>>
>>>>>> Based on the above, I personally don't think that it would make
>>>>>> sense to progress RFC4941 to Internet Standard, but rather think
>>>>>> that we should work on a replacement of it -- our proposal being
>>>>>> draft-gont-6man-non-stable-iids-01.
>>>>>>
>>>>>> Thoughts?
>>>>>
>>>>> Certainly any update on 4941 needs to be done in the light of a few
>>>>> deficiencies that have emerged over the years, and the publication of
>>>>> RFC7217.
>>>>>
>>>>> I think it’s still possible to do a -bis off 4941.
>>>>
>>>> My questions would be:
>>>>
>>>> 1) Can you actually address the aforementioned deficiencies without
>>>> significant changes to RFC4941? -- It would seem to me that in order to
>>>> address them, rfc4941bis would not be a bis document anymore.
>>>>
>>>> 2) If you were to address such deficiencies, could the bis document be
>>>> progressed to Internet Standard? -- My assessment of this question
>>>> is: No.
>>>>
>>>> If RFC4941 would take significant work, and the end result would
>>>> actually be significantly different from what's in RFC4941, then I'm not
>>>> sure that'd be different than starting from the I-D we already have...
>>>
>>> Just to be clear, I like the material in your new draft.
>>>
>>> That said, it seems you could do a similar style of update from 3041
>>> to 4941, with a similar structure; the content is there in your draft,
>>> it “just" needs to be merged in.
>>>
>>> That would mean obsoleting 4941, just as 4941 obsoleted 3041. So you
>>> would include the details in 4941 that would carry forward.
>>
>> <AD hat off>. I agree. If we are planning a drop in replacement to
>> RFC4941 creating a bis document from there is the right thing to do.
>
> Can you explain your rationale? (along with answering the two questions
> I posed to Tim).
>
> RFC4941 can be summarized as consisting of two parts:
>
> 1) A discussion of privacy implications of Identifiers, and of IIDs in
> particular
>
> 2) Specification of an algorithm to generate the IID
>
>
> "1)" was much needed when RFC3041 was published, and then carried to
> RFC4941 (when it was probably still needed). Nowadays, the security and
> privacy properties of IPv6 addresses are discussed more thoroughly (and
> in more dimensions) in RFC7721. And the discussion of identifiers in
> documents such as RFC6973 and draft-gont-predictable-numeric-ids
> (besides the fact that one can always refer back to RFC3041 or even
> RFC4941 for such discussion, in the same way we referenced RFC3041 in
> RFC7721).
>
> When it comes to "2)", if you really want to address the issues found in
> RFC4941, essentially you need to replace the algorithm with something
> else. One may tweak a few things here and there (e.g., the update we
> propose in our I-D), but still there are drawbacks in RFC4941 that
> cannot be addressed without fundamentally changing the algorithm (for
> instance, RFC4941 has notable drawbacks when compared to simply
> generating the IID as a random number that is not tied to previously
> selected IIDs). If one were to do rfc4941bis, such document could not be
> progressed to STD. And since there are better and/or alternative
> approaches for generating temporary addresses, I'm not sure what would
> be the benefit here.

But the structure of your document is exactly the same as 3041 and 4941:

3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Generation of Temporary IPv6 Addresses . . . . . . . . . . . 6
5. Update to existing RFCs . . . . . . . . . . . . . . . . . . . 8

Basically, it's “the problem” and “generating temporary addresses”.

I think we are discussing two things that are actually quite similar in structure.

Tim

[Lorenzo Colitti]

On Thu, Jul 20, 2017 at 1:34 PM, Tim Chown <***@jisc.ac.uk> wrote:

> But the structure of your document is exactly the same as 3041 and 4941:
>
> 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3
> 4. Generation of Temporary IPv6 Addresses . . . . . . . . . . . 6
> 5. Update to existing RFCs . . . . . . . . . . . . . . . . . . . 8
>
> Basically, it's “the problem” and “generating temporary addresses”.
>
> I think we are discussing two things that are actually quite similar in
> structure.
>

+1

[Fernando Gont]

On 07/20/2017 02:34 PM, Tim Chown wrote:
>> On 20 Jul 2017, at 12:03, Fernando Gont <***@si6networks.com> wrote:
>>
>> On 07/20/2017 11:21 AM, Suresh Krishnan wrote:
>>> Hi Tim,
>>>
>>>> On Jul 19, 2017, at 6:00 PM, Tim Chown <***@jisc.ac.uk
>>>> <mailto:***@jisc.ac.uk>> wrote:
>>>>
>>>>> On 19 Jul 2017, at 13:57, Fernando Gont <***@si6networks.com
>>>>> <mailto:***@si6networks.com>> wrote:
>>>>>
>>>>> On 07/19/2017 01:58 PM, Tim Chown wrote:
>>>>>>> On 18 Jul 2017, at 15:52, Fernando Gont <***@si6networks.com
>>>>>>> <mailto:***@si6networks.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> Among the list of RFCs to be progressed to full std is/was RFC4941
>>>>>>> ("Privacy Extensions for Stateless Address Autoconfiguration in
>>>>>>> IPv6").
>>>>>>>
>>>>>>> As it stands, RFC4941 has a number of issues:
>>>>>>>
>>>>>>> * Using the same IID for multiple prefixes * Not changing the IID
>>>>>>> upon "security events" (including e.g., change in the underlying
>>>>>>> MAC address) * Using MD5 as opposed to something better * Requiring
>>>>>>> the use of temporary addresses along stable addresses (preventing
>>>>>>> use of temporary-only, for nodes that feel like) * Not treating
>>>>>>> IIDs as opaque values (see RFC7136) when generating the randomized
>>>>>>> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one
>>>>>>> specific algorithm, when the same goals/properties can be achieved
>>>>>>> with multiple algorithms (see section 4 of
>>>>>>> draft-gont-6man-non-stable-iids-01)
>>>>>>>
>>>>>>>
>>>>>>> Based on the above, I personally don't think that it would make
>>>>>>> sense to progress RFC4941 to Internet Standard, but rather think
>>>>>>> that we should work on a replacement of it -- our proposal being
>>>>>>> draft-gont-6man-non-stable-iids-01.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>
>>>>>> Certainly any update on 4941 needs to be done in the light of a few
>>>>>> deficiencies that have emerged over the years, and the publication of
>>>>>> RFC7217.
>>>>>>
>>>>>> I think it’s still possible to do a -bis off 4941.
>>>>>
>>>>> My questions would be:
>>>>>
>>>>> 1) Can you actually address the aforementioned deficiencies without
>>>>> significant changes to RFC4941? -- It would seem to me that in order to
>>>>> address them, rfc4941bis would not be a bis document anymore.
>>>>>
>>>>> 2) If you were to address such deficiencies, could the bis document be
>>>>> progressed to Internet Standard? -- My assessment of this question
>>>>> is: No.
>>>>>
>>>>> If RFC4941 would take significant work, and the end result would
>>>>> actually be significantly different from what's in RFC4941, then I'm not
>>>>> sure that'd be different than starting from the I-D we already have...
>>>>
>>>> Just to be clear, I like the material in your new draft.
>>>>
>>>> That said, it seems you could do a similar style of update from 3041
>>>> to 4941, with a similar structure; the content is there in your draft,
>>>> it “just" needs to be merged in.
>>>>
>>>> That would mean obsoleting 4941, just as 4941 obsoleted 3041. So you
>>>> would include the details in 4941 that would carry forward.
>>>
>>> <AD hat off>. I agree. If we are planning a drop in replacement to
>>> RFC4941 creating a bis document from there is the right thing to do.
>>
>> Can you explain your rationale? (along with answering the two questions
>> I posed to Tim).
>>
>> RFC4941 can be summarized as consisting of two parts:
>>
>> 1) A discussion of privacy implications of Identifiers, and of IIDs in
>> particular
>>
>> 2) Specification of an algorithm to generate the IID
>>
>>
>> "1)" was much needed when RFC3041 was published, and then carried to
>> RFC4941 (when it was probably still needed). Nowadays, the security and
>> privacy properties of IPv6 addresses are discussed more thoroughly (and
>> in more dimensions) in RFC7721. And the discussion of identifiers in
>> documents such as RFC6973 and draft-gont-predictable-numeric-ids
>> (besides the fact that one can always refer back to RFC3041 or even
>> RFC4941 for such discussion, in the same way we referenced RFC3041 in
>> RFC7721).
>>
>> When it comes to "2)", if you really want to address the issues found in
>> RFC4941, essentially you need to replace the algorithm with something
>> else. One may tweak a few things here and there (e.g., the update we
>> propose in our I-D), but still there are drawbacks in RFC4941 that
>> cannot be addressed without fundamentally changing the algorithm (for
>> instance, RFC4941 has notable drawbacks when compared to simply
>> generating the IID as a random number that is not tied to previously
>> selected IIDs). If one were to do rfc4941bis, such document could not be
>> progressed to STD. And since there are better and/or alternative
>> approaches for generating temporary addresses, I'm not sure what would
>> be the benefit here.
>
> But the structure of your document is exactly the same as 3041 and 4941:
>
> 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3
> 4. Generation of Temporary IPv6 Addresses . . . . . . . . . . . 6
> 5. Update to existing RFCs . . . . . . . . . . . . . . . . . . . 8
>
> Basically, it's “the problem” and “generating temporary addresses”.
>
> I think we are discussing two things that are actually quite similar in structure.

Just trying to get a clear picture in my head: Does the discussion boil
down to renaming "draft-gont-6man-non-stable-iids" to
"draft-gont-6man-rfc4941bis"?

My mental model is that a bis document essentially incorporates errata
and minor changes to a previous RFC. But this doesn't seem whre we want
to go here.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Tim Chown]

> On 20 Jul 2017, at 12:58, Fernando Gont <***@si6networks.com> wrote:
>
> On 07/20/2017 02:34 PM, Tim Chown wrote:
>>> On 20 Jul 2017, at 12:03, Fernando Gont <***@si6networks.com> wrote:
>>>
>>> On 07/20/2017 11:21 AM, Suresh Krishnan wrote:
>>>> Hi Tim,
>>>>
>>>>> On Jul 19, 2017, at 6:00 PM, Tim Chown <***@jisc.ac.uk
>>>>> <mailto:***@jisc.ac.uk>> wrote:
>>>>>
>>>>>> On 19 Jul 2017, at 13:57, Fernando Gont <***@si6networks.com
>>>>>> <mailto:***@si6networks.com>> wrote:
>>>>>>
>>>>>> On 07/19/2017 01:58 PM, Tim Chown wrote:
>>>>>>>> On 18 Jul 2017, at 15:52, Fernando Gont <***@si6networks.com
>>>>>>>> <mailto:***@si6networks.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Folks,
>>>>>>>>
>>>>>>>> Among the list of RFCs to be progressed to full std is/was RFC4941
>>>>>>>> ("Privacy Extensions for Stateless Address Autoconfiguration in
>>>>>>>> IPv6").
>>>>>>>>
>>>>>>>> As it stands, RFC4941 has a number of issues:
>>>>>>>>
>>>>>>>> * Using the same IID for multiple prefixes * Not changing the IID
>>>>>>>> upon "security events" (including e.g., change in the underlying
>>>>>>>> MAC address) * Using MD5 as opposed to something better * Requiring
>>>>>>>> the use of temporary addresses along stable addresses (preventing
>>>>>>>> use of temporary-only, for nodes that feel like) * Not treating
>>>>>>>> IIDs as opaque values (see RFC7136) when generating the randomized
>>>>>>>> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one
>>>>>>>> specific algorithm, when the same goals/properties can be achieved
>>>>>>>> with multiple algorithms (see section 4 of
>>>>>>>> draft-gont-6man-non-stable-iids-01)
>>>>>>>>
>>>>>>>>
>>>>>>>> Based on the above, I personally don't think that it would make
>>>>>>>> sense to progress RFC4941 to Internet Standard, but rather think
>>>>>>>> that we should work on a replacement of it -- our proposal being
>>>>>>>> draft-gont-6man-non-stable-iids-01.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Certainly any update on 4941 needs to be done in the light of a few
>>>>>>> deficiencies that have emerged over the years, and the publication of
>>>>>>> RFC7217.
>>>>>>>
>>>>>>> I think it’s still possible to do a -bis off 4941.
>>>>>>
>>>>>> My questions would be:
>>>>>>
>>>>>> 1) Can you actually address the aforementioned deficiencies without
>>>>>> significant changes to RFC4941? -- It would seem to me that in order to
>>>>>> address them, rfc4941bis would not be a bis document anymore.
>>>>>>
>>>>>> 2) If you were to address such deficiencies, could the bis document be
>>>>>> progressed to Internet Standard? -- My assessment of this question
>>>>>> is: No.
>>>>>>
>>>>>> If RFC4941 would take significant work, and the end result would
>>>>>> actually be significantly different from what's in RFC4941, then I'm not
>>>>>> sure that'd be different than starting from the I-D we already have...
>>>>>
>>>>> Just to be clear, I like the material in your new draft.
>>>>>
>>>>> That said, it seems you could do a similar style of update from 3041
>>>>> to 4941, with a similar structure; the content is there in your draft,
>>>>> it “just" needs to be merged in.
>>>>>
>>>>> That would mean obsoleting 4941, just as 4941 obsoleted 3041. So you
>>>>> would include the details in 4941 that would carry forward.
>>>>
>>>> <AD hat off>. I agree. If we are planning a drop in replacement to
>>>> RFC4941 creating a bis document from there is the right thing to do.
>>>
>>> Can you explain your rationale? (along with answering the two questions
>>> I posed to Tim).
>>>
>>> RFC4941 can be summarized as consisting of two parts:
>>>
>>> 1) A discussion of privacy implications of Identifiers, and of IIDs in
>>> particular
>>>
>>> 2) Specification of an algorithm to generate the IID
>>>
>>>
>>> "1)" was much needed when RFC3041 was published, and then carried to
>>> RFC4941 (when it was probably still needed). Nowadays, the security and
>>> privacy properties of IPv6 addresses are discussed more thoroughly (and
>>> in more dimensions) in RFC7721. And the discussion of identifiers in
>>> documents such as RFC6973 and draft-gont-predictable-numeric-ids
>>> (besides the fact that one can always refer back to RFC3041 or even
>>> RFC4941 for such discussion, in the same way we referenced RFC3041 in
>>> RFC7721).
>>>
>>> When it comes to "2)", if you really want to address the issues found in
>>> RFC4941, essentially you need to replace the algorithm with something
>>> else. One may tweak a few things here and there (e.g., the update we
>>> propose in our I-D), but still there are drawbacks in RFC4941 that
>>> cannot be addressed without fundamentally changing the algorithm (for
>>> instance, RFC4941 has notable drawbacks when compared to simply
>>> generating the IID as a random number that is not tied to previously
>>> selected IIDs). If one were to do rfc4941bis, such document could not be
>>> progressed to STD. And since there are better and/or alternative
>>> approaches for generating temporary addresses, I'm not sure what would
>>> be the benefit here.
>>
>> But the structure of your document is exactly the same as 3041 and 4941:
>>
>> 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3
>> 4. Generation of Temporary IPv6 Addresses . . . . . . . . . . . 6
>> 5. Update to existing RFCs . . . . . . . . . . . . . . . . . . . 8
>>
>> Basically, it's “the problem” and “generating temporary addresses”.
>>
>> I think we are discussing two things that are actually quite similar in structure.
>
> Just trying to get a clear picture in my head: Does the discussion boil
> down to renaming "draft-gont-6man-non-stable-iids" to
> "draft-gont-6man-rfc4941bis"?
>
> My mental model is that a bis document essentially incorporates errata
> and minor changes to a previous RFC. But this doesn't seem whre we want
> to go here.

I think the purpose and spirit are very similar though, just with a few years of extra experience.

One of the RFC4941 authors is explicitly copied above; have a chat :)

(That’s what I did for example with 6724 and 6434-bis)

Tim

[神明達哉]

At Thu, 20 Jul 2017 12:42:17 +0000,
Tim Chown <***@jisc.ac.uk> wrote:

> > My mental model is that a bis document essentially incorporates errata
> > and minor changes to a previous RFC. But this doesn't seem whre we want
> > to go here.
>
> I think the purpose and spirit are very similar though, just with a few years of extra experience.

Even if not, I don't think a bis document can't do anything beyond
incorporating errata and minor changes. The revised version of the
advanced socket API (now published as RFC3542) was named
draft-ietf-ipngwg-rfc2292bis and changed the RFC2292 API so
substantially, many of which are completely new or backwarnd
incompatible. That's an old example that I just happen to be involved
with, but I believe there are newer such examples.

In some cases a bis draft is actually really conservative, e.g., when
it intends to elevate the status of the original RFC, but in my
understanding there's no rule that other kinds of update can't have a
bis name.

BTW, I don't have a strong opinion on how to name the draft in
question per se. But if I were to choice, I'd actually use
'rfc4941bis', since it would help tell people looking at RFC4941 the
existence of an update attempt.

--
JINMEI, Tatuya

[Brian E Carpenter]

On 20/07/2017 23:58, Fernando Gont wrote:
...
> My mental model is that a bis document essentially incorporates errata
> and minor changes to a previous RFC. But this doesn't seem whre we want
> to go here.

I think that is actually an over-interpretation** of the suffix "bis".

It isn't in any way an IETF rule, it's just a habit (copied from ISO
or ITU-T, I suspect). All it tells me is that draft-something-rfc9999bis
is intended to *obsolete and replace* RFC 9999. That doesn't mean that
it is based directly on the text of RFC 9999, although it might be, and
often is, for convenience.

It's only an ill-defined naming convention, in the end.

** and the dictionary meaning is different: twice; for a second time; again; once more.

Brian

[Francis Dupont]

> Among the list of RFCs to be progressed to full std is/was RFC4941
> ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6").

=> I even published a document explaining what I thought about the
whole idea (and I didn't change my mind).

> As it stands, RFC4941 has a number of issues:
> * Using MD5 as opposed to something better

=> for this use MD5 is not bad. Just consider it as a not crypto hash.

Now RFC4941bis is currently heavily deployed so it is far too soon
to try to obsolete it.

When I went to the mic at a previous IETF meeting some years ago
to ask the IPv6 specs to be raise to full standard with at first
the IPv6 protocol itself (done, THANKS!!!). If the RFC4941 is left
at the border of the road I shan't be sad...

Regards

***@fdupont.fr

[Fernando Gont]

Hello, Francis,

On 07/19/2017 02:17 PM, Francis Dupont wrote:
>> Among the list of RFCs to be progressed to full std is/was RFC4941
>> ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6").
>
> => I even published a document explaining what I thought about the
> whole idea (and I didn't change my mind).

COuld you please provide a reference?



>> As it stands, RFC4941 has a number of issues:
>> * Using MD5 as opposed to something better
>
> => for this use MD5 is not bad. Just consider it as a not crypto hash.
>
> Now RFC4941bis is currently heavily deployed so it is far too soon
> to try to obsolete it.

I'm not necessarily thinking about obsoleting it. This is, say, an open
question. I do think that you cannot move RFC4941 to STD, though.



> When I went to the mic at a previous IETF meeting some years ago
> to ask the IPv6 specs to be raise to full standard with at first
> the IPv6 protocol itself (done, THANKS!!!). If the RFC4941 is left
> at the border of the road I shan't be sad...

I don't think RFC4941 meet the criteria for elevating a document to STD,
though.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Francis Dupont]

In your previous mail you wrote:

> On 07/19/2017 02:17 PM, Francis Dupont wrote:
> >> Among the list of RFCs to be progressed to full std is/was RFC4941
> >> ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6").
> >
> > => I even published a document explaining what I thought about the
> > whole idea (and I didn't change my mind).
>
> COuld you please provide a reference?

=> https://tools.ietf.org/html/draft-dupont-ipv6-rfc3041harmful-05
Note my concerns were integrated into RFC 4941 so they should look
like pretty basic/old now.

> > Now RFC4941bis is currently heavily deployed so it is far too soon
> > to try to obsolete it.
>
> I'm not necessarily thinking about obsoleting it. This is, say, an open
> question. I do think that you cannot move RFC4941 to STD, though.

=> I understand well it is a different question but IMHO your
ultimate goal is to obsolete RFC 4941 (with other words I should not
believe you if you answer you never had this idea :-).

> > When I went to the mic at a previous IETF meeting some years ago
> > to ask the IPv6 specs to be raise to full standard with at first
> > the IPv6 protocol itself (done, THANKS!!!). If the RFC4941 is left
> > at the border of the road I shan't be sad...
>
> I don't think RFC4941 meet the criteria for elevating a document to STD,
> though.

=> so at least we don't disagree...

Regards

***@fdupont.fr

[Francis Dupont]

When following a number it can get a specific meaning: in a postal
address bis (and ter) means something was inserted between two
numbers (usually between N and N + 2 as streets have an even side
and an odd side).

In the IETF context I agree "bis" means more a revamp and major
changes come from consolidation with other related documents
published after.

So in the RFC4941bis particular case the name is really arguable
and IMHO if the new mechanism is not backward compatible the bis
name should not be used.

Now the I-D name is temporary so it should be more important to
discuss about its content...

Regards

***@fdupont.fr

[Johanna Ullrich]

>> Now the I-D name is temporary so it should be more important to
>> discuss about its content...
+1

Beyond Fernando's issues, I'd like to add the following:
* Subsequent addresses are concatenated with each other.
* There is no entropy added when calculating the next IID based on the current history value.
* Instead, only values that are likely to be known by other parties (MAC addresses) are included.
* Initial randomization of the algorithm is rather low (only 64 bits).

With regard to the specific algorithms that are proposed in draft-gont-6man-non-stable-iids:
I prefer to use randomized IIDs as it bears advantages. If a random number generator became vulnerable at some point in the future, the generator would be fixed anyway and the privacy extension implementation would automatically benefit. In addition, no alternative version of the privacy extension for devices without stable storage is needed.

The algorithm of RFC 4941 must not be used. An adversary is able to perform address correlation having reasonable effort, and protection against such attacks is the privacy extension's one and only purpose.

Regards,
Johanna Ullrich

________________________________________
Von: ipv6 <ipv6-***@ietf.org> im Auftrag von Francis Dupont <***@fdupont.fr>
Gesendet: Freitag, 21. Juli 2017 09:40
An: Brian E Carpenter
Cc: Fernando Gont; Suresh Krishnan; ***@ietf.org
Betreff: Re: "RFC4941bis" and draft-gont-6man-non-stable-iids

When following a number it can get a specific meaning: in a postal
address bis (and ter) means something was inserted between two
numbers (usually between N and N + 2 as streets have an even side
and an odd side).

In the IETF context I agree "bis" means more a revamp and major
changes come from consolidation with other related documents
published after.

So in the RFC4941bis particular case the name is really arguable
and IMHO if the new mechanism is not backward compatible the bis
name should not be used.

Now the I-D name is temporary so it should be more important to
discuss about its content...

Regards

***@fdupont.fr

--------------------------------------------------------------------
IETF IPv6 working group mailing list
***@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------