Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-15.txt

Eric,

I hope to do last read through today or tomorrow.   I was only commenting on Brian’s email.  I will look for the -16 when it is out.

Thanks,
Bob

> On Mar 11, 2019, at 1:44 AM, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
> 
> Brian and Bob,
> 
> First of all, thank you for the quick review. And especially, the text around EUI-64 & SLAAC which we, the authors, will gladly accept.
> 
> In order to progress with this draft, the authors will issue today a -16 where the ULA section will simply be reduced to mention the ULA considerations draft. With this, we hope to remove the last (?) blocking factor for this OPsecv6 draft.
> 
> Regards
> 
> -éric
> 
> On 09/03/2019, 22:56, "OPSEC on behalf of Brian E Carpenter" <opsec-bounces@ietf.org on behalf of brian.e.carpenter@gmail.com> wrote:
> 
>    Hi,
> 
>    A few comments. (Note that I am not on the opsec list, so please CC me on any replies.)
> 
>> 2.1.2. Use of ULAs
>    ....
>> It is tempting to think that ULAs could be useful for infrastructure
>> hiding as described in [RFC4864];...
> 
>    That's a very strange choice of words, and ignores the actual argument
>    for this choice, which is that internal communications using ULAs
>    are doubly protected from accidental external visibility. If you want
>    to say that RFC4864 was wrong, please argue that explcitly. Otherwise
>    please be neutral, e.g.:
> 
>    ULAs could be used for infrastructure hiding as described in [RFC4864];...
> 
>> It is recommended to consider filtering packets with ULA source	
>> addresses or ULA destination addresses at the domain boundary.
> 
>    Actually RFC4193 is already stronger than that. Filtering ULA routes
>    is a "must", and filtering packets containing ULA source or destination
>    is a "should" (unless explicitly configured otherwise). I think you
>    should not weaken this here!
> 
>> 2.1.4.  Temporary Addresses - Privacy Extensions for SLAAC
>> 
>> Historically stateless address autoconfiguration (SLAAC) relies on	
>> the automatically generated EUI-64 address,which together with the	
>> /64 prefix makes up the global unique IPv6 address.
> 
>    That's inaccurate. Try:
> 
>    Historically, stateless address autoconfiguration (SLAAC) relied on	
>    an automatically generated 64 bit interface identifier (IID) based
>    on the EUI-64 MAC address, which together with the /64 prefix makes
>    up the globally unique IPv6 address.
> 
>    ....
>> As [RFC4941] privacy extension addresses could also be used to
>> obfuscate some malevolent activities (whether on purpose or not),
>> specific user attribution/accountability procedures must be put in
>> place as described in section Section 2.6.
> 
>    That "must" is a bit strange. It seems too much to say "MUST",
>    so why not make it "SHOULD"?
> 
>    Regards
>       Brian Carpenter
> 
>    _______________________________________________
>    OPSEC mailing list
>    OPSEC@ietf.org
>    https://www.ietf.org/mailman/listinfo/opsec
> 
> 
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec