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

[Erik Kline via Datatracker <[e-mail]>]

Erik Kline has entered the following ballot position for
draft-ietf-opsec-v6-25: Discuss

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/



----------------------------------------------------------------------
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"?

[ 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 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?


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