Subject: Re: AD Evaluation: draft-ietf-6man-stable-privacy-addresses

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Nov 2013 05:21:19 -0300

Hi, Brian,

My apologies for the delay in my response. Looks like this one
remained unanswered.

On 10/29/2013 12:42 PM, Brian Haberman wrote:
> All, I have completed my AD evaluation for 
> draft-ietf-6man-stable-privacy-addresses and only have a few 
> comments/questions that I would like to get some feedback on...
> 
> 1. It would be useful to include an *informative* reference or two 
> for candidate PRFs.

I have added the following text to the I-D:

   MD5 <xref target="RFC1321"/> and SHA-1 <xref target="FIPS-SHS"/> are
   two possible options for F()

in the (bullet) definition of F().

And this:

   For informative purposes, we note that MD5 <xref target="RFC1321"/>
   and SHA-1 <xref target="FIPS-SHS"/> are two possible options for F().

in the discussion of the properties of F():

> 2. Given the opaque bits discussion in section 5, I think it would 
> be good to include a reference to the 6man-ug draft to provide the
>  justification.

Good grief! -- I've just added it where the "opaque bits" thing is
mentioned.

> 3. Section 6 discusses the benefits of using the DAD_Counter in
> the PRF call, but I think the draft should also mention the
> downsides to not maintaining that variable in non-volatile memory
> over reboots. Specifically, the scenario where a node used
> IDGEN_RETRIES attempts on the previous boot to get a valid address
> and during the current boot will fail if it needs IDGEN_RETRIES+1
> tries and DAD_Counter info is not stored.

This seems to be already discussed in Section 6:

   In those unlikely scenarios in which duplicate addresses are detected
   and in which the order in which the conflicting nodes configure their
   addresses may vary (e.g., because they may be bootstrapped in
   different order), the algorithm specified in this section for
   resolving DAD conflicts could lead to addresses that are not stable
   within the same subnet.  In order to mitigate this potential problem,
   nodes MAY record the DAD_Counter value employed for a specific
   {Prefix, Net_Iface, Network_ID} tuple in non-volatile memory, such
   that the same DAD_Counter value is employed when configuring an
   address for the same Prefix and subnet at any other point in time.
   We note that the use of non-volatile memory is OPTIONAL, and hosts
   that do not implement this feature are still compliant to this
   protocol specification.

i.e., if you don't keep this in stable memory, this method might
result in different addresses (i.e., the resulting addresses might not
be stable).

> 4. I am agnostic on this one, but want some feedback.  Should the 
> reference to the address-generation-privacy draft be normative 
> given that it contains the necessary background info supporting 
> this approach?

I've kept this one as Informative, since it's not "something you need
to read to understand this specification". FWIW, some folks had the
same view a while ago.

> Once we agree on these points, we can move the draft along in the 
> publication process.

I've just rev'ed the document as per the above comments. If there's
anything left, please do let me know so that I can apply any further
changes and rev again.

Thanks!

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

---

From: Dan Luedtke <[email-masked]>
Date: Tue, 26 Nov 2013 16:43:06 +0100

Hi Fernando,

a quick question regarding the following part:
> The resulting Interface Identifier SHOULD be compared against the
> Subnet-Router Anycast [RFC4291] and the Reserved Subnet Anycast
> Addresses [RFC2526], and against those Interface Identifiers
> already employed in an address of the same network interface and
> the same network prefix.  In the event that an unacceptable
> identifier has been generated, this situation SHOULD be handled
> in the same way as the case of duplicate addresses (see
> Section 6).

Why do you use SHOULD here? What is the use of allowing to use any of
the reserved addresses?

Best regards

Dan

-- 
Dan Luedtke
http://www.danrl.de

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Nov 2013 13:02:16 -0300

> Why do you use SHOULD here? What is the use of allowing to use any of

Are you arguing in favor of a MUST rather than a SHOULD, or something else?

For the first instance, the second instance, or both?

For the first one, I guess some could argue that this could be a "MUST"
-- although some argue that we should forget about special case IIDs (in
a similar way that we did for U/G bits).

For the second one, IIRC it has to do with the fact that we currently do
not require recovery from DAD for other methods. But I guess some might
argue in favor of  "MUST" here, too.

Thoughts? Others?

Thanks!

Best regards,

---

From: Dan Luedtke <[email-masked]>
Date: Wed, 27 Nov 2013 08:52:34 +0100

Hi,

> Are you arguing in favor of a MUST rather than a SHOULD, or something else?
As long as there is no good reason for using reserved IIDs (like
Subnet Router Anycast etc.) I argue in favor for MUST for the first
instance. For the second instance I think a MUST would provide the
most predictable behavior. Since I have no idea what other methods my
be suitable to solve the issue for the second instance, I would not
like to argue in favor for either one (MUST, SHOULD).   If I had to
implement the RFC, I would handle both instances as if the SHOULD were
a MUST. Just to save code and complexity. As I understand comparing to
a fixed list of reserved identifiers also does not introduce any new
security implications.

What do others think?

Best Regards,

Dan

-- 
Dan Luedtke
http://www.danrl.de

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Nov 2013 08:23:01 +1300

> a fixed list of reserved identifiers also does not introduce any new

The (small, polite) elephant in the room is: what happens if a new
reserved IID is defined at some point in the future? All deployed
code will instantly fail to implement the MUST, so we need to
proceed as if any reserved IID might be used at any time. (We
mention this in the IANA Considerations of draft-ietf-6man-ug.)

My conclusion is therefore that it absolutely doesn't matter in
practice whether it's MUST or SHOULD.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Nov 2013 15:10:53 -0300

Hi, Brian,

> practice whether it's MUST or SHOULD.

Could you please elaborate a bit?

Thanks,