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

From: [email-masked]
Date: Sat, 09 Mar 2019 12:32:12 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF.

        Title           : Operational Security Considerations for IPv6 Networks
        Authors         : Eric Vyncke
                          Kiran K. Chittimaneni
                          Merike Kaeo
                          Enno Rey
	Filename        : draft-ietf-opsec-v6-15.txt
	Pages           : 50
	Date            : 2019-03-09

Abstract:
   Knowledge and experience on how to operate IPv4 securely is
   available: whether it is the Internet or an enterprise internal
   network.  However, IPv6 presents some new security challenges.  RFC
   4942 describes the security issues in the protocol but network
   managers also need a more practical, operations-minded document to
   enumerate advantages and/or disadvantages of certain choices.

   This document analyzes the operational security issues in several
   places of a network (enterprises, service providers and residential
   users) and proposes technical and procedural mitigations techniques.
   Some very specific place of a network such as Internet of Things are
   not discussed in this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsec-v6-15
https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-15

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/

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Mar 2019 10:55:49 +1300

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

---

From: Bob Hinden <[email-masked]>
Date: Sat, 9 Mar 2019 16:16:39 -0800

Brian,

> On Mar 9, 2019, at 1:55 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 
> ....
> ULAs could be used for infrastructure hiding as described in [RFC4864];…

+1

> should not weaken this here!

RFC4864 also describes this.

Bob

> ....
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 11 Mar 2019 08:44:40 +0000

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-masked] on behalf of [email-masked]> wrote:

    Hi,

    ....

    

    
    That's inaccurate. Try:

    ....

    Regards
       Brian Carpenter

---

From: Bob Hinden <[email-masked]>
Date: Mon, 11 Mar 2019 07:35:40 -0700

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-masked]> wrote:
> 
> Brian and Bob,
>