Subject: Re: [OPSEC] RtgDir: Last Call Review of draft-ietf-opsec-v6-21.txt - "Operational Security Considerations for IPv6 Networks"

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 9 Feb 2021 11:10:18 +0000

Hello Acee,

Thank you for your directorate review and sorry for such a belated reply!

Special thanks for the DIFF containing suggestions for improving the text. Most of them have been applied (none of the authors is English native so such assistance is welcome)

Look below for EV> for more comments.

Regards

-éric

-----Original Message-----
From: "Acee Lindem (acee)" <[email-masked]>
Date: Tuesday, 3 December 2019 at 17:21
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Routing Directorate <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [OPSEC] RtgDir: Last Call Review of draft-ietf-opsec-v6-21.txt - "Operational Security Considerations for IPv6 Networks"

     Hello,

    I have been selected as the Routing Directorate reviewer for this draft.
    The Routing Directorate seeks to review all routing or routing-related
    drafts as they pass through IETF last call and IESG review, and
    sometimes on special request. The purpose of the review is to provide
    assistance to the Routing ADs. For more information about the Routing
    Directorate, please see ​

      http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

    Although these comments are primarily for the use of the Routing ADs,
    it would be helpful if you could consider them along with any other
    IETF Early Review/Last Call  comments that you receive, and strive to
    resolve them through discussion or by updating the draft.

    Document: draft-ietf-opsec-v6-21.txt
    Reviewer: Acee Lindem
    Review Date: 12/2/2019
    IETF LC End Date: Soon
    Intended Status:  Informational

    Summary: The document contains a lot of useful recommendations and
             references for Operational Security in IPv6 networks. Since
                    the document has "Informational" status, none of the text is
                    normative.

                    While the information content is very good, parts of the
                    document are very hard to read and need revision. In general,
                    the usage of long clauses connected by semicolons should be
                    discouraged and the lists connected in this manner should
                    be replaced with complete sentences. I've attached a diffs
                    with editorial suggests but didn't try and rewrite all the
                    semicolon connected text segments.

EV> let's hope that the RFC Editor will find and remediate those long constructs.

                    There are also minor issues that need to be addressed.

    Major Issues: None

    Minor Issues:

        1. Section 1.0 - What do you mean by "updating it with that have been
           standardized since 2007."? It just doesn't read right.

EV> text has been simplified in -23

        2. Section 2.1 - IPv4 also allows multiple addresses per interface,
           i.e., secondary addresses. So what is new?

EV>  last sentence now reads as
 "Having by default multiple
   IPv6 addresses per interface is a major change compared to the unique
   IPv4 address per interface for hosts (secondary IPv4 addresses are
   not common); especially for audits (see section Section 2.6.2.3)."

        3. Section 2.1.5 - The whole discussion on how to use Router
           Advertisement (RA) messages lacks enough context to understand.
           Also, expand RA in the first occurrence.

EV> text was not clear indeed, changed

        4. Section 2.2.3 - Expand out NDP since it is not clear that it is
           Neighbor Discovery Protocol from the context. It is expanded later
           in section 2.3.

EV> thanks, fixed

        5. Section 2.4 - RFC 6192 not only defines the "router control plane"
            but provides much better guidance for control plane filtering than
            section 2.4.1 and 2.4.2.

EV> text updated

        6. Section 2.4.1 and 2.4.2 - The ingress ACL should only be applied on
           the packets punted to the RP.

EV> indeed, added

        7. Section 2.4.1 - If OSPFv3 vitual links are used, the destination
           address will not be a link-local address.

EV> trusting you on this one, text modified

        8. Section 2.4.3 - Suggest references for Path MTU Discovery
           and traceroute.

EV> good idea

        9. Section 2.5.1 - HMAC MD5 is considered vulnerable.

EV> let's indeed remove this paragraph

       10. Section 2.5.2 - What prior section describes the operational
           costs of IPsec?

EV> oups the previous section was deleted revisions ago...

       11. Section 2.5.3 - Need expansion and reference for RADB.

EV> indeed, added reference to https://www.radb.net/ 

       12. Section 2.6 - Need expansion and reference for GDPR.

EV> indeed, added reference to https://eur-lex.europa.eu/eli/reg/2016/679/oj

       13. Section 2.7.1 - ACLs are typically per address family so this
           recommendation isn't
           really feasible. Please revise.

EV> I disagree, this is a platform limitation. Text unchanged.

       14. Section 2.7.2.6 - Expand MAP-E and MAP-T.

EV> done

       15. Section 3.1 and 4.1 - Define bogon and provide reference.

EV> done, added reference to CYMRU

       16. Section 3.2 - Bad reference in fourth paragraph.

EV> fixed in -22

       17. Section 5 - Suggest references for Teredo tunnels and NAT-PT.
           Also, expand NAT-PT on first occurrence.

EV> good idea for Teredo (added) and NAPT is now defined in section 1

    Nits: Attached diff with suggested edits.

EV> big thanks for them

    Thanks,
    Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 9 Feb 2021 11:28:52 +0000

Hi Eric,

Thanks for incorporating my comments. See one inline. 

On 2/9/21, 6:10 AM, "Eric Vyncke (evyncke)" <[email-masked]> wrote:

    Hello Acee,

    Regards

    -éric

    -----Original Message-----
    From: "Acee Lindem (acee)" <[email-masked]>
    Date: Tuesday, 3 December 2019 at 17:21
    To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
    Cc: Routing Directorate <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: [OPSEC] RtgDir: Last Call Review of draft-ietf-opsec-v6-21.txt - "Operational Security Considerations for IPv6 Networks"

         Hello,

        Major Issues: None

        Minor Issues:

    EV> thanks, fixed

    EV> text updated

    EV> indeed, added

    EV> good idea

ACEE> I don't know of a platform that doesn't have this limitation. Also, the IETF YANG model is organized with all ACL entries in an ACL being the same type. 

See excerpt from RFC 8519:

  list acl {
      key "name";
      description
        "An ACL is an ordered list of ACEs.  Each ACE has a
         list of match criteria and a list of actions.
         Since there are several kinds of ACLs implemented
         with different attributes for different vendors,
         this model accommodates customizing ACLs for
         each kind and for each vendor.";
      leaf name {
        type string {
          length "1..64";
        }
        description
          "The name of the access list.  A device MAY further
           restrict the length of this name; space and special
           characters are not allowed.";
      }
      leaf type {
        type acl-type;
        description
          "Type of ACL.  Indicates the primary intended
           type of match criteria (e.g., Ethernet, IPv4, IPv6, mixed,
           etc.) used in the list instance.";
      }

However, I don't feel that strongly. 

Thanks,
Acee

    EV> done

    EV> fixed in -22

    EV> big thanks for them

        Thanks,
        Acee

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 9 Feb 2021 12:01:54 +0000

Acee, 

I appreciate the quick reply of yours ;-)

About, a shared ACL between IPv4 and IPv6, if the YANG model has one separate ACL per address family, then it is broken (<AD hat> I was not yet the INT AD at that time </AD hat>). 

Most of the firewalls (also a layer-3 device) have a single ACL for both address families and now, let's not conflate the actual TCAM implementation (that is obviously per address family) with the CLI or management interfaces that SHOULD (really) be protocol agnostic.

Anyway, you kindly wrote " However, I don't feel that strongly." ;-)

Regards,

-éric

-----Original Message-----
From: "Acee Lindem (acee)" <[email-masked]>
Date: Tuesday, 9 February 2021 at 12:28
To: Eric Vyncke <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Routing Directorate <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OPSEC] RtgDir: Last Call Review of draft-ietf-opsec-v6-21.txt - "Operational Security Considerations for IPv6 Networks"

    Hi Eric,

        Hello Acee,

        Regards

        -éric

        -----Original Message-----
        From: "Acee Lindem (acee)" <[email-masked]>
        Date: Tuesday, 3 December 2019 at 17:21
        To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
        Cc: Routing Directorate <[email-masked]>, "[email-masked]" <[email-masked]>
        Subject: [OPSEC] RtgDir: Last Call Review of draft-ietf-opsec-v6-21.txt - "Operational Security Considerations for IPv6 Networks"

             Hello,

            Major Issues: None

            Minor Issues:

        EV> thanks, fixed

        EV> text updated

        EV> indeed, added

        EV> good idea

      list acl {
          key "name";
          description

    Thanks,
    Acee

        EV> done

        EV> fixed in -22

        EV> big thanks for them

            Thanks,
            Acee