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

From: Lars Eggert via Datatracker <[email-masked]>
Date: Tue, 06 Apr 2021 08:00:09 -0700

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
+                                                                     ^^

---

From: Enno Rey <[email-masked]>
Date: Sat, 10 Apr 2021 20:39:26 +0200

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

-- 
Enno Rey

Cell: +49 173 6745902
Twitter: @Enno_Insinuator