Subject: AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03

From: Margaret Wasserman <[email-masked]>
Date: Tue, 10 May 2005 09:19:14 -0400

Hi All,

I have a few AD Review comments on 
draft-ietf-ipv6-privacy-addrs-v2-03 that I would like to have 
resolved before I send this document to IETF LC.  I've included those 
comments below.

Brian and Bob, the tracker indicates that this document is intended 
for publication as a Draft Standard, however RFC 3041 is currently at 
PS, and this document seems to contain some changes to the 
specification that would impact implementations (such as the 
requirement to perform DAD on all generated addresses).  Is the 
tracker state correct?  If so, what is the rationale for publishing 
this document at DS?

Thanks,
Margaret

>>  I think that sometihng went wrong with the structure of this document:

Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
      1.1   Problem Statement  . . . . . . . . . . . . . . . . . . . .  5
      1.2   Conventions used in this document  . . . . . . . . . . . .  5

>>  Why is the RFC 2119 section inside the problem statement?

    2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  6
      2.1   Extended Use of the Same Identifier  . . . . . . . . . . .  6
      2.2   Address Usage in IPv4 Today  . . . . . . . . . . . . . . .  7
      2.3   The Concern With IPv6 Addresses  . . . . . . . . . . . . .  8
      2.4   Possible Approaches  . . . . . . . . . . . . . . . . . . .  9

>>  Is section 2 supposed to be part of the problem statement?

3.  Protocol Description

    The goal of this section is to define procedures that:

    1.  Do not result in any changes to the basic behavior of addresses
        generated via stateless address autoconfiguration [ADDRCONF].
    2.  Create additional global scope addresses based on a random
        interface identifier for use with global scope addresses.

>>  What is meant by "for use with global addresses"?  is this intended
    to be a restriction on how/when privacy addresses can be used?

3.1  Assumptions

    The following algorithm assumes that each interface maintains an
    associated randomized interface identifier.  When temporary addresses
    are generated, the current value of the associated randomized
    interface identifier is used.  The actual value of the identifier
    changes over time as described below, but the same identifier can be
    used to generate more than one temporary address.

    The algorithm also assumes that for a given temporary address, an
    implementation can determine the prefix from which it was generated.
    When a temporary address is deprecated, a new temporary address is
    generated.  The specific valid and preferred lifetimes for the new
    address are dependent on the corresponding lifetime values set for
    the prefix from which it was generated.

>>  These two paragraphs are confusing to me.  The node maintains a
    random IID from which multiple addresses can be generated of the
    form <prefix, IID>, right?  These addresses will become deprecated
    when their lifetime expires, and new addresses will be generated.
    The implementation keeps track of what prefix was used to generate
    the addres and generates a new address for that prefix, right?
    Does it also need to generate a new random IID when this happens?
    In other words, is there anything in this mechanism that prevents
    generating the same privacy address again on the same interface
    using the same prefix and the same random IID (if it hasn't expired
    yet)?

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 11 May 2005 10:15:23 -0400 (EDT)

Hi Margaret,
   Thanks for the comments. Please see my replies inline.

Thanks
Suresh

>>>  Why is the RFC 2119 section inside the problem statement?

It is just another sub section under introduction to the document and is 
not under the problem statement. I can move this to a separate section if 
you feel strongly about this.

>>>  Is section 2 supposed to be part of the problem statement?

The problem statement is a concise description of the threat model we are 
defending against. Section 2 is a much more detailed study of the problems 
involved. The problem statement was created to provide the reader with 
some context as to why the document is needed. So the problem statement is 
a summary of sorts of section 2.

>   to be a restriction on how/when privacy addresses can be used?

This is not an intended restriction. I can reword it to read

"2. Create additional addresses based on a random interface identifier for
     the purpose of initiating outgoing sessions"

instead of

"2. Create additional global scope addresses based on a random
    interface identifier for use with global scope addresses.Such
    addresses would be used to initiate outgoing sessions."

Does that sound OK?

>   using the same prefix and the same random IID (if it hasn't expired

The mechanism certainly allows this behavior but it kind of defeats the 
purpose(to not have a stable interface identifier). The requirement to 
change the random interface identifier is a SHOULD and is described in 
section 3.5

" Nodes following this specification SHOULD generate new temporary
   addresses on a periodic basis.  This can be achieved automatically by
   generating a new randomized interface identifier at least once every
   (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units."

If you think this is should be a stronger requirement I can change it to a 
MUST at the cost of breaking backward compatibility. Let me know what you 
prefer.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 13 May 2005 13:50:39 -0400

At 10:15 AM -0400 5/11/05, Suresh Krishnan wrote:
>It is just another sub section under introduction to the document 
>and is not under the problem statement. I can move this to a 
>separate section if you feel strongly about this.

Oh, okay...  I viewed the Problem Statement and the Background both 
as parts of the problem statement.  Maybe if you just switched the 
order of 1.1 and 1.2 (so the RFC 2119 language comes first), that 
would be better.  Or, just ignore this issue, as it is purely 
editorial.

>The problem statement is a concise description of the threat model 
>we are defending against. Section 2 is a much more detailed study of 
>the problems involved. The problem statement was created to provide 
>the reader with some context as to why the document is needed. So 
>the problem statement is a summary of sorts of section 2.

Okay.

>    addresses would be used to initiate outgoing sessions."

Yes, that is better.

>The mechanism certainly allows this behavior but it kind of defeats 
>the purpose(to not have a stable interface identifier). The 
>requirement to change the random interface identifier is a SHOULD 
>and is described in section 3.5
>
>If you think this is should be a stronger requirement I can change 
>it to a MUST at the cost of breaking backward compatibility. Let me 
>know what you prefer.

The SHOULD is fine, but perhaps you could change the first paragraph 
of section 3.1 to read:

    The following algorithm assumes that each interface maintains an
    associated randomized interface identifier.  When temporary addresses
    are generated, the current value of the associated randomized
    interface identifier is used.  While the same identifier can be used to
    create more than one temporary address, the value SHOULD change
    over time as described in section 3.5.

This would make it clearer that a person should look at section 3.5 
to understand how the identifier will change over time.

Margaret

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 24 May 2005 19:30:44 -0400 (EDT)

Hi Margaret,
   Thanks for the comments and the text. I have submitted version -04 of 
the draft with the suggested changes. Let me know if you have any more 
issues you would like me to address.

Cheers
Suresh

On Fri, 13 May 2005, Margaret Wasserman wrote:

>> It is just another sub section under introduction to the document and is not 
>> under the problem statement. I can move this to a separate section if you 
>> feel strongly about this.
>
> Oh, okay...  I viewed the Problem Statement and the Background both as parts 
> of the problem statement.  Maybe if you just switched the order of 1.1 and 1.2 
> (so the RFC 2119 language comes first), that would be better.  Or, just ignore 
> this issue, as it is purely editorial.
>
>> involved. The problem statement was created to provide the reader with some 
>> context as to why the document is needed. So the problem statement is a 
>> summary of sorts of section 2.
>
> Okay.
>
>>>  3.  Protocol Description
>>> 
> The SHOULD is fine, but perhaps you could change the first paragraph of 
> section 3.1 to read:
>
> This would make it clearer that a person should look at section 3.5 to 
> understand how the identifier will change over time.
>
> Margaret
>
>
>
>

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 25 May 2005 08:04:32 -0400

Hi Suresh,

Thanks for the quick turnaround!

When the new draft comes out, I will send it to IETF LC.  After we 
make it through IETF LC, the document will be reviewed by the full 
IESG.  So, at this point, there are no further changes that need to 
be made, but you may need to make changes based on comments at either 
of those later review points.

Thanks again for your quick response.

Margaret

At 7:30 PM -0400 5/24/05, Suresh Krishnan wrote:
>Hi Margaret,
>   Thanks for the comments and the text. I have submitted version -04 
>of the draft with the suggested changes. Let me know if you have any 
>more issues you would like me to address.
>
>Cheers
>Suresh