Ballot deferred by Benjamin Kaduk on 2021-04-07.
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
[ section 2.1 ] * "may also force the use of NPTv6" seems like it draws some conclusions. Perhaps something like: "may also increase the perceived need for the use of NPTv6"? [ section 2.2 ] * "It must also be noted that there is no indication in the IPv6 packet as to whether the Next Protocol field points to an extension header or to a transport header." What is this trying to say? Is this about what 8200 calls the "Next Header" field? If so, the Next Header field indicates...the next header, and whether that's a transport header or not depends on its value. I guess I read this text as implying that the 8200 standard is somehow ambiguous about what NH means, but it's really not. It's just that NH does not always indicate a transport. [ section 22.214.171.124 ] * "Only trivial cases [...] should have RA-guard..." Only? This doesn't strike me as being obviously the best recommendation. Definitely in trivial cases it should be enabled, but surely it should also be enabled even in more complex cases, albeit ones where knowledgeable administrators can configure things appropriately (vis. the applicability statement in section 1.1)...maybe?
[ general ] * There are many uses of ellipses ("...") that probably could be tightened up (usually just removed might work). [ section 2.1.1 ] * I think it never hurts to repeat the message that ULA /48s from the fd00::/8 space (L=1) MUST be generated with a pseudo-random algorithm, per RFC 4193 sections 3.2, 3.2.1, &c. [ section 2.1.4 ] * I think the opening sentence might clarify that it's talking about stable address assignment for nodes. On a one-pass reading, section 2.1.3 immediately preceding this is discussing router loopback addressing, so I found I had routers on the brain when I started 2.1.4. [ section 2.1.5 ] * Up to you, but 4941 has been superseded by 8981. [ section 2.1.6 ] * "(see Section 126.96.36.199)" -> I think the trailing ")" probably wants to be at the end of that sentence; if not, it does not quite make grammatical sense (to me). [ section 2.2.3 ] * s/ipv6/IPv6/g [ section 2.3.5 ] * As an addendum to the final paragraph, it might be noted that such filtering can inhibit mDNS (whether or not that's a desirable outcome). [ section 2.4 ] * "non-legit": perhaps a bit too casual? [ section 188.8.131.52 ] * "as currently collected as in" -> "as currently collected in", I suspect [ section 184.108.40.206 ] * There are other motivations for doing forensic analysis that simply investigating "malicious activity" (even if this is the most common motivation). As a concrete proposal, perhaps: "At the end of the process, the interface of the host originating, or the subscriber identity associated with, the activity in question has been determined." ...or something [ section 2.7.2 ] * "legit": perhaps a bit too casual? "legitimate"? Or perhaps just s/legit and//. [ section 220.127.116.11 ] * s/IPV4/IPv4/ * Consider port 123 NTP in your allowlist. :-) * "hardly never" -> "hardly ever" [ section 18.104.22.168 ] * Does this section belong in this document? It's all about IPv4, and not even particular to IPv4 in the presence of IPv6 -- just IPv4 in general. [ section 22.214.171.124 ] * "DNSSEC has an impact on DNS64" It might also be said that "DNS64 has an impact on DNSSEC", so perhaps "DNSSEC and DNS64 negatively interact"? [ section 4.3 ] * "and what the respective log retention" -> "and the respective log retention", I think
I haven't gone through the dozens of references to verify the claims about them, so I'm trusting the WG and ADs here... In Sec 126.96.36.199, RA-Guard and SAVI are recommended, but then in the same paragraph it says that "only trivial cases" should enable it by default. I can't reconcile these two statements.
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 188.8.131.52, 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 184.108.40.206, 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 220.127.116.11, 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 18.104.22.168, 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 22.214.171.124, 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 + ^^
(1) The applicability statement in §1.1 is confusing to me. a. The Abstract says that "this document are not applicable to residential user cases", but that seems not to be true because this section says that the contents do apply to "some knowledgeable-home-user-managed residential network[s]", and §5 is specific to residential users. b. "This applicability statement especially applies to Section 2.3 and Section 2.5.4." Those two sections represent a small part of the document; what about the rest? It makes sense to me for the applicability statement to cover most of the document. c. "For example, an exception to the generic recommendations of this document is when a residential or enterprise network is multi-homed." I'm not sure if this sentence is an example of the previous one (above) or if "for example" is out of place. (2) §5 mentions "early 2020" -- I assume that the statement is still true now. (3) It caught my attention that there's only one Normative Reference (besides rfc8200, of course). Why? What is special about the IPFIX registry? It seems that an argument could be made to the fact that to secure OSPFv3, for example, an understanding of the protocol is necessary. This argument could be extended to other protocols or mechanisms, including IPv6-specific technology: ND, the addressing architecture, etc. Consider the classification of the references in light of .  https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
I found this document very informative and I learned quite a lot by reading this document (I must confess I haven't read the long list of referenced documents :-)). I think the collected recommendations in one place will be very helpful. Some comments - * The abstract says - "The recommendations in this document are not applicable to residential user cases". However, later on in section 1.1 it says - "This covers Service Provider (SP), enterprise networks and some knowledgeable-home-user-managed residential network." Furthermore in section 5, it recommends configurations for residential users. May be I am not getting the distinction among residential user cases, managed residential network and residential users correct but I think further clarification is needed on what is written in thee abstract and what is in the rest of the document. * I noted that section 2.3.4 refers to 3GPP 4G terminologies while describing the case. If this section is not supposed to restricted to certain generations of 3GPP technologies then I would recommend to update the section with 5G terminologies as well. * In section 2.6 there is an ask for the network operators to log "of all applications using the network (including user space and kernel space) when available (for example web servers)". How realistic is this? I hardly see the web servers sharing logging files with network operators ( I would be happy to be corrected here ). I am also missing the discussion on -- if not available how much this affects the forensic research in the event of security incident and abnormal behavior.
As I am an author... BTW, did you notice the publication date?