Re: [OPSEC] Erik Kline's Discuss on draft-ietf-opsec-v6-25: (with DISCUSS and COMMENT)

[Erik Kline <[e-mail]>]

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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/opsec
>
> --
> Enno Rey
>
> Cell: [phone]
> Twitter: @Enno_Insinuator