Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Fernando,

Thanks very much for your response.

On 4/22/13 6:06 PM, Fernando Gont wrote:
> Hi, Eliot,
>
> On 04/22/2013 01:20 AM, Eliot Lear wrote:
>> In the process of doing the apps area review, I came across some points
>> that were not related to applications.  The basis for these comments is
>> precisely the sentiment that Russ Housley expressed, which is that the
>> specification is done when there is no more to remove.
> I'd probaby disagree with such statement. One thing is removing tuff
> from the mechanism or algorithm that you're standardizing, in the hopes
> of keeping it simple (this one I'd agree with). Another is removing text
> from specifications, which essentially means that the gut implementing
> the spec has more to figure out by himself, and hence more chances for
> failures.

Fair point, of course.

>
>
>>  With this
>> document, I wonder if quite a bit could be removed.
>>
>> Specifically, a great deal of discussion goes into the PRF involving DAD
>> counters, etc, when all that is needed is a suitable PRF.
> Not sure what you mean...What's thetext that you think could/should be
> removed?

Sorry I wasn't clear: what is the benefit of specifying the algorithm,
when simply popping out another PRF will in just about any instance do
the job (unless you are reinitializing the PRF with the same seed)?

>
>
>> The draft in
>> fact says this in Section 3 after an explanation of the inputs.  Any PRF
>> that follows the guidelines of RFC 4086 should do fine and not cause
>> interoperability OR security problems.
> If you're referring to the text that explains why we're not mandating
> any specific PRF, that text is there because the issue was raisen in the wg,

Ok.  So what I gather is that there was a negotiation within the WG and
that the algorithm is optional.  Ok.  From an outside point of view, I
didn't need to know that, and the question is what was the value of
still specifying the PRF.  I think Ran Atkinson answered that.  He feels
he wants a fully specified algorithm from which to start.  Ok.  My only
response is that I don't understand the need (generating 64 bits that
aren't the same shouldn't be that hard), but if the WG really believes
there is one, okay.


>
>
>> Also, the following text in section 3 Page 7 is contorted:
>>
>>       This means that this document does not formally obsolete or
>>       deprecate any of the existing algorithms to generate Interface IDs
>>       (e.g. such as that specified in [RFC2464]).  However, those IPv6
>>       implementations that employ this specification must generate all
>>       of their "stable" addresses as specified in this document.
>>
>> My suggestion is to simplify remove it as it is self-evident.
> What's the part that is evident? The one about not deprecating existing
> algorithms? -- Because the other ne certainly isn't: if you're going to
> use this algorithm for generating addresses *in addition* to those
> generated by traditional SLAAC, then this document wouldn't mitigate
> address-scanning attacks.

How would an IPv6 implementation employing this specification vary from
this specification in a way you or the working group would find
objectionable?  Also, did you mean "MUST"?  If not, this language is all
the more confusing and I don't know what you mean.

>> Finally, this algorithm requires that the resultant host portion be 64
>> bits.  Is that necessary?
> Well, yes- If the PRF produces a bit string larger than 64 bits,  and
> you say nothing about how you grab the IID, then the algorithm is
> underspecified.
>
> The easier it is for a developer to go through this document and come up
> with an implementation, the better. The more the open questions, the worse.
>

I think we are underestimating our developers but if the working group
feels differently, okay.  I asked the above question because it is at
least conceivable that at some point host portion != 64 bits and this is
the only place in the document where the requirement is stated.  Yes,
screwing with the 64 bit boundary today is bound to cause all sorts of
breakage.  I'm not thinking of today but the future.  And yes, another
argument would be that there isn't enough address space for this to be
effectively private.  Those are two different issues, but fixing the
boundary here reminds me of mistakes we made with IPv4 way back when. 
In this day and age we're talking about a lot more cleanup later.

Eliot




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]