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

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