Re: I-D Action: draft-ietf-6man-default-iids-11.txt

[Brian E Carpenter <[e-mail]>]

Hi Gengyu,

>> RID is not random or random identifier according to the context above.
>> 
>> F() is an inreverse function, not a pseudorandom function.

I agree that this is incorrect use of terminology; an irreversible hash is
not mathematically equivalent to a pseudo-random number generator. But the
effect is the same: an attacker has no way to predict the next F(x) or to
obtain the value of x. As far as practical engineering goes, F() can be treated
as a random number. So I don't see why this invalidates the use of RFC 7217.

You could submit an erratum for RFC 7217 at http://www.rfc-editor.org/errata.php#reportnew
so that the terminology can be corrected when the document is updated.

Regards
   Brian Carpenter

On 16/05/2016 18:11, weigengyu wrote:
> Hi all,
> 
> Is it not a problem to promote RFC7217 in which concept errors are existed?
> 
> RFC7217 did not only giving a definition of stable address, but also defining an algorithm to generate it.
> The algorithm contains concept error in my opinion.
> 
>>
>>        Title           : Recommendation on Stable IPv6 Interface Identifiers
>>        Authors         : Fernando Gont
>>                          Alissa Cooper
>>                          Dave Thaler
>>                          Will Liu
>> Filename        : draft-ietf-6man-default-iids-11.txt
>> Pages           : 23
>> Date            : 2016-04-27
>>
>> Abstract:
>>   This document changes the default scheme for generating stable
>>   Interface Identifiers with SLAAC to that specified in RFC7217, and
>>   recommends against embedding link-layer addresses in IPv6 Interface
>>   Identifiers.
> 
> 
> Regards,
> 
> Gengyu WEI
> Network Technology Center
> School of Computer
> Beijing University of Posts and Telecommunications
> 
> -----原始邮件----- From: weigengyu
> Sent: Monday, May 09, 2016 2:35 PM
> To: Alissa Cooper
> Cc: [e-mail]
> Subject: Re: I-D Action: draft-ietf-6man-default-iids-11.txt
> 
> Hi，
> 
>> This document changes the default scheme for generating stable
>   Interface Identifiers with SLAAC to that specified in RFC7217,
> 
> There is a question about RFC7217 as this draft is to promote it.
> In RFC7217,  in Page 6 and page 7,  "5.  Algorithm Specification"
> "1.  Compute a random (but stable) identifier with the expression:
>       RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)
>       Where:
>       RID:
>          Random (but stable) Identifier
>       F():
>          A pseudorandom function (PRF) that MUST NOT be computable from
>          the outside (without knowledge of the secret key).  F() MUST
>          also be difficult to reverse, such that it resists attempts to
>          obtain the secret_key, even when given samples of the output
>          of F() and knowledge or control of the other input parameters.
>          F() SHOULD produce an output of at least 64 bits.  F() could
>          be implemented as a cryptographic hash of the concatenation of
>          each of the function parameters.  SHA-1 [FIPS-SHS] and SHA-256
>          are two possible options for F().  Note: MD5 [RFC1321] is
>          considered unacceptable for F() [RFC6151]. "
> 
> It seems it is a concept error for RID.
> RID is not random or random identifier according to the context above.
> 
> F() is an inreverse function, not a pseudorandom function.
> Within parameters of F(Prefix, Net_Iface, Network_ID, DAD_Counter,
> secret_key),
> only the secret_key is generated by a pseudorandom function.
> But the secret_key is also a constant because it keeps unchanged after being
> generated.
> 
> There are not random features.
> 
> The question is why it is called RID, Random ID?
> 
> 
> Regards,
> 
> Gengyu WEI
> Network Technology Center
> School of Computer
> Beijing University of Posts and Telecommunications
> -----原始邮件----- From: Alissa Cooper
> Sent: Thursday, April 28, 2016 10:41 PM
> To: IETF IPv6 Mailing List
> Subject: Re: I-D Action: draft-ietf-6man-default-iids-11.txt
> 
> This version incorporates comments based on discussion before and during
> IETF 95 (thanks to Fernando for spinning the rev). I think this version
> addresses the comments received and should be ready to move forward.
> 
> Alissa
> 
> 
>> On Apr 27, 2016, at 5:49 PM, [e-mail] wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the IPv6 Maintenance of the IETF.
>>
>>        Title           : Recommendation on Stable IPv6 Interface Identifiers
>>        Authors         : Fernando Gont
>>                          Alissa Cooper
>>                          Dave Thaler
>>                          Will Liu
>> Filename        : draft-ietf-6man-default-iids-11.txt
>> Pages           : 23
>> Date            : 2016-04-27
>>
>> Abstract:
>>   This document changes the default scheme for generating stable
>>   Interface Identifiers with SLAAC to that specified in RFC7217, and
>>   recommends against embedding link-layer addresses in IPv6 Interface
>>   Identifiers.  It formally updates RFC2464, RFC2467, RFC2470, RFC2491,
>>   RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338,
>>   RFC4391, RFC5072, and RFC5121, by removing the text in these RFCs
>>   that required the IPv6 Interface Identifiers to be derived from the
>>   underlying link-layer address, and replacing the aforementioned text
>>   with a pointer to this document.  Additionally, this document updates
>>   RFC3315 by specifying additional requirements on the generation of
>>   Interface Identifiers used in Dynamic Host Configuration Protocol
>>   version 6 (DHCPv6).  It also provides advice to system administrators
>>   who employ manual configuration.  This document does not change any
>>   existing recommendations concerning the use of temporary addresses as
>>   specified in RFC 4941.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-6man-default-iids/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-6man-default-iids-11
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-default-iids-11
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------