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

From: Erik Kline via Datatracker <[email-masked]>
Date: Tue, 06 Apr 2021 21:18:27 -0700

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

---

From: Enno Rey <[email-masked]>
Date: Fri, 9 Apr 2021 00:49:54 +0200

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:

That's a good point & proposed change; we'll incorporate 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.

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

> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

-- 
Enno Rey

Cell: +49 173 6745902
Twitter: @Enno_Insinuator

---

From: Erik Kline <[email-masked]>
Date: Thu, 8 Apr 2021 18:26:14 -0700

Enno,

Broadly these proposed changes seem good to me.  I look forward to
reading the next version.

Thanks!

---

From: Enno Rey <[email-masked]>
Date: Sat, 10 Apr 2021 20:53:42 +0200

Erik,

> reading the next version.

It has been uploaded in the interim.
I incorporated those proposed changes, and I also performed a number of additional changes which should address your COMMENTs (plus those of other reviewers).

May I kindly ask you to clear your DISCUSS once you had the time to look at the revised version (and, evidently, you consider the changes sufficiently clarifying)?
Thanks again very much for the extensive review.

Wish you a great weekend,

Enno

-- 
Enno Rey

Cell: +49 173 6745902