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