Enno, Broadly these proposed changes seem good to me. I look forward to reading the next version.
Thanks! On Thu, Apr 8, 2021 at 3:49 PM Enno Rey <[email protected]> wrote: > > Hi Erik, > > thank you very much for the detailed feedback. > Based on that, and on some other reviewers' comments, we plan to do some > edits, more specifically: > > > > On Tue, Apr 06, 2021 at 09:18:27PM -0700, Erik Kline via Datatracker wrote: > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > [ 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"? > > That's a good point & proposed change; we'll incorporate that. > > > > > > [ 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. > > I have in mind to replace the above sentence by the following: > "Vendors of filtering solutions and operations personnel [responsible for > implementing packet filtering rules] should be aware that the 'Next Header' > field in an IPv6 header can both point to an IPv6 extension header or to an > upper layer protocol header. This has to be kept in mind [or: considered] > when designing the UX of filtering solutions or during the creation of > [filtering] rule sets." > > From ypur perspective, would this provide sufficient clarification with > regard to the potential problem space? This was about misconceptions among > security operators, not about RFC 8200 ambiguities. I hope my suggested > sentence makes this clear. > > > > > > [ section 2.3.2.4 ] > > > > * "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? > > I agree with what you're writing. Point is that other reviewers pointed out > that they see cases where RA-Guard would be counterproductve. I hence suggest > to replace the phrase ("Only trivial cases") by the following: > > "Enabling RA-Guard by default in Wi-Fi networks or enterprise campus networks > should be [strongly] considered unless specific circumstances [or: use cases] > such as the presence of Homenet devices emitting router advertisements > preclude this." > > Would that make sense, from your point of view? > > We will also address the majority of your COMMENTs in the next revision. > Thank you again for providing those, and the above (very valid) points. > > Enno > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > [ 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 2.6.1.5)" -> 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 2.6.1.7 ] > > > > * "as currently collected as in" -> "as currently collected in", I suspect > > > > [ section 2.6.2.1 ] > > > > * 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 2.7.2.8 ] > > > > * s/IPV4/IPv4/ > > > > * Consider port 123 NTP in your allowlist. :-) > > > > * "hardly never" -> "hardly ever" > > > > [ section 2.7.3.1 ] > > > > * 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 2.7.3.2 ] > > > > * "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 > > > > > > > > _______________________________________________ > > OPSEC mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/opsec > > -- > Enno Rey > > Cell: +49 173 6745902 > Twitter: @Enno_Insinuator _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
