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) <[email protected]> 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" > <[email protected] on behalf of [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/opsec > > > _______________________________________________ > OPSEC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
