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

[Enno Rey <[e-mail]>]

Hi Lars,

thank you for the extensive evaluation/feedback.

I went through all your COMMENTs and I've performed a number of adaptions/corrections. We subsequently uploaded a new version of the draft.

Thanks again for pointing out those items,
cheers

Enno

On Tue, Apr 06, 2021 at 08:00:09AM -0700, Lars Eggert via Datatracker wrote:
> 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
> +                                                                     ^^
> 
> 
> 

-- 
Enno Rey

Cell: [phone]
Twitter: @Enno_Insinuator