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: +49 173 6745902 Twitter: @Enno_Insinuator _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
