Re: [OPSEC] Lars Eggert's No Objection on draft-ietf-opsec-v6-25: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

[Wearing only the authors' hat]

Hello Lars,

Thank you very much for your detailed review. I know that it takes time and effort ;-)

Together with my co-authors, we have uploaded revision -27, which should addresses all your comments and nits.

The diff is at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-27

Regards

-éric

-----Original Message-----
From: iesg <[e-mail]> on behalf of Lars Eggert via Datatracker <[e-mail]>
Reply-To: Lars Eggert <[e-mail]>
Date: Tuesday, 6 April 2021 at 17:00
To: The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Lars Eggert's No Objection on draft-ietf-opsec-v6-25: (with COMMENT)

    Lars Eggert has entered the following ballot position for
    draft-ietf-opsec-v6-25: No Objection

    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)


    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Section 2.3.1, paragraph 6, comment:
    >    o  Tuning of NDP process (where supported).

    Tuning in which way?

    Section 2.7.2, paragraph 2, comment:
    >    There are many tunnels used for specific use cases.  Except when
    >    protected by IPsec [RFC4301], all those tunnels have a couple of
    >    security issues as described in RFC 6169 [RFC6169];

    IPsec is not the only security mechanism that will protect tunnels, most
    tunnel encryption mechanisms would.

    -------------------------------------------------------------------------------
    All comments below are very minor change suggestions that you may choose to
    incorporate in some way (or ignore), as you see fit. There is no need to let me
    know what you did with these suggestions.

    Section 2.5.3, paragraph 4, nit:
    >    Many routing protocols support the use of cryptography to protect the
    >    routing updates, the use of this protection is recommended; [RFC8177]
    >    is a YANG data model key chains including the renewal.
    >

    I can't parse the part after the semicolon.

    Section 2.6.2.2, paragraph 9, nit:
    Might also want to mention http://www.entropy-ip.com/ and similar tools.

    Section 2.2.3, paragraph 3, nit:
    -       not contain the entire ipv6 header chain (including the transport-
    -                              ^^
    +       not contain the entire IPv6 header chain (including the transport-
    +                              ^^

    Section 2.2.3, paragraph 4, nit:
    -       contain the entire ipv6 header chain (including the transport-
    -                          ^^
    +       contain the entire IPv6 header chain (including the transport-
    +                          ^^

    Section 2.2.4, paragraph 2, nit:
    -    the updated IPv6 Nodes Requirement standard [RFC8504] IPsec is a
    +    the updated IPv6 Nodes Requirement standard [RFC8504], IPsec is a
    +                                                         +

    Section 2.3, paragraph 2, nit:
    -    operations such as discovering other nodes on the link, resolving
    +    operations, such as discovering other nodes on the link, resolving
    +              +

    Section 2.3, paragraph 2, nit:
    -    secured, NDP is vulnerable to various attacks such as router/neighbor
    +    secured, NDP is vulnerable to various attacks, such as router/neighbor
    +                                                 +

    Section 2.3, paragraph 2, nit:
    -    documented in IPv6 ND Trust Models and Threats [RFC3756] and in

    Section 2.3.1, paragraph 2, nit:
    -    Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial
    +    The Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial
    +   ++++

    Section 2.3.1, paragraph 6, nit:
    -    o  Using /127 on point-to-point link per [RFC6164].
    +    o  Using a /127 on a point-to-point link, per [RFC6164].
    +             ++       ++                    +

    Section 2.3.2.3, paragraph 2, nit:
    -    on-link prefix; 3GPP Section 2.3.4 uses a similar mechanism.
    +    on-link prefix; 3GPP (see Section 2.3.4) uses a similar mechanism.
    +                         +++++             +

    Section 2.3.3, paragraph 2, nit:
    -    Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described
    -    in [RFC8415], enables DHCP servers to pass configuration parameters
    -    such as IPv6 network addresses and other configuration information to
    -    IPv6 nodes such as a hostile recursive DNS server.  DHCP plays an
    +    The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described
    +   ++++
    +    in [RFC8415], enables DHCP servers to pass configuration parameters,
    +                                                                       +
    +    such as IPv6 network addresses and other configuration information, to
    +                                                                      +
    +    IPv6 nodes, such as a hostile recursive DNS server.  DHCP plays an
    +              +

    Section 2.3.3, paragraph 3, nit:
    -    of-service attack or to mount on path attack.  While unintentional, a
    -                                    ^
    +    of-service attack or to mount an on-path attack.  While unintentional, a
    +                                  +++  ^

    Section 2.3.4, paragraph 2, nit:
    -    address.  This implies there can only be an end host (the mobile
    -                                             ^
    +    address.  This implies there can only be one end host (the mobile
    +                                             ^ +

    Section 2.3.4, paragraph 2, nit:
    -    address built by the mobile host.  The GGSN/PGW always provides an
    -            ^^^^
    +    address generated by the mobile host.  The GGSN/PGW always provides an
    +            ^^^^^^ ++

    Section 2.3.4, paragraph 4, nit:
    -    link model, NDP on it and the address configuration details.  In some
    -                   ------
    +    link model, NDP and the address configuration details.  In some

    Section 2.5, paragraph 8, nit:
    -    interface where it is required.
    +    interfaces where it is required.
    +             +

    Section 2.5.4, paragraph 2, nit:
    -    pertain to edge route filtering vs internal route filtering.  At a
    +    pertain to edge route filtering vs. internal route filtering.  At a
    +                                      +

    Section 2.6.1.5, paragraph 2, nit:
    -    clients.  It is indeed quite similar to DHCP for IPv4 so it can be
    +    clients.  It is indeed quite similar to DHCP for IPv4, so it can be
    +                                                         +

    Section 2.6.1.5, paragraph 3, nit:
    -    It is not so easy in the IPv6 networks because not all nodes will use
    -                         ----
    +    It is not so easy in IPv6 networks, because not all nodes will use
    +                                      +

    Section 2.7.3.1, paragraph 2, nit:
    -    Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT
    -                                                   ^^^
    +    Carrier-Grade NAT (CGN), also called NAT444 CGN, Large Scale NAT
    +                                                   ^

    Section 4.3, paragraph 3, nit:
    -    (e.g., his/her PPP session, physical line, or CPE MAC address).  With
    -                                                                     ^^^^
    +    (e.g., his/her PPP session, physical line, or CPE MAC address).  In
    +                                                                     ^^