Subject: [Last-Call] Opsdir last call review of draft-ietf-opsec-v6-25

From: Tim Chown via Datatracker <[email-masked]>
Date: Wed, 07 Apr 2021 02:12:37 -0700

Reviewer: Tim Chown
Review result: Has Issues

Hi,

I have reviewed this document (draft-ietf-opsec-v6-25) as part of the
Operational directorate's ongoing effort to review all IETF documents being
processed by the IESG.  These comments were written with the intent of
improving the operational aspects of the IETF drafts. Comments that are not
addressed in last call may be included in AD reviews during the IESG review. 
Document editors and WG chairs should treat these comments just like any other
last call comments.

This draft analyses operational security issues related to the deployment of
IPv6, and describes appropriate mechanisms and practices to mitigate potential
threats.

I had previously reviewed the draft as an OPS-DIR Early Review in July 2018,
and again since then, so am familiar with the document and its history.

General comments:

The document has evolved over time with many topics added, and has an
inevitable “Frankenstein” feel to it.  The document would be much better for a
rewrite, but that would be significant work, and would delay publication
further.  The material in the document is good, and the advice is valuable, so
the focus should be on publishing it sooner rather than later, and thus the
issues with structure are probably best overlooked.

An example of the historical evolution of the document are the instances where
the same topic os covered multiple times.  This would ideally be avoided.

The section most in need of attention is 2.1, where many aspects of addressing
are weaved together: allocations, assignments, assignment to hosts, ULAs,
stable and temporary addresses, etc.  This might be better presented as a
section listing addressing related security issues, such as privacy for users,
first hop security, network manageability, implications of multi-addressed
hosts, address accountability (which isn’t mentioned here?), avoiding
renumbering (if that is security?), etc.

There are also some sections which summarise recommendations, or reinforce
them, and others that do not.  For a document of over 50 pages, which is quite
a long read, it would be desirable to have a summary of the key
recommendations, either at the end of each 2nd level topic, or as a standalone
section at the end of the document where the key points of each 2nd level topic
are summarised.

Is it worth citing examples of security toolkits readers can explore, like the
THC kit, SI6 Networks, etc, maybe Scapy?

Specific comments:

p.3
I don’t understand why NPTv6 is mentioned here, this early.  Just say that some
security issues have IPv4 equivalents, like ND attacks and ARP attacks, and
some do not, like IPv6 EHs or hop by hop DoS.   The NAT discussion should be in
a standalone section, and be neutral there.

p.4
Why mention the specific example of multi-homed networks?   What do you mean by
the exception?  Is it that multi-homing is out of scope, and so are unmanaged
networks?

p.4
Again, NPTv6 is mentioned.  This section is titled “addressing architecture”
but this bit of text is about reasons for going PA, PI, or becoming an LIR,
which is not architecture.

p.4
In the 7934 para, RFC8981 should be mentioned as it’s a significant reason of
devices having more addresses.

p.5
ULAs are also useful where the prefix changes, for stable internal addressing
as the global prefix changes?  Typically in residential networks.

p.5
Section 2.1.4 is really about choices in address assignment within a network.

p.6
Some of these paras should be in a section about IPv6 network reconnaissance,
how to best mitigate against scanning, and how to inventory your own network
elements.

p.6
All mentions of 4941 should be replaced with 8981.

p.7
Can use 7721 and 8981 together.

p.7
Why are DHCP and DNS limped together?  The DNS is only about DNSSEC, so call it
that?

p.7
“Even if the use of DHCP” - this reads badly.  Rather 8504 talks about this in
6.5, where RFC7844 is mentioned for example.  This should be in a user privacy
section (if this document had one).  Section 8.4 is also useful advice.

p.8
The first para is very muddled.

p.8
In 2.1.7 this can also be useful for ACL controls, if one admin / control
system sits in a prefix of its own.

p.10
This is really about handling of fragmented packets (the topic) not the
fragment header itself Also this is covered in 2.3.2.1 as well.

p.10
In 2.2, the intro can say these issues have parallels in IPv4.

p.11
First line, say the attack can typically happen from a large address scan if
permitted into the network?

p.11
Bullet 1 - that contradicts the comments on predictable addressing.
Bullet 2 - how?  Some clues here would be useful.

p.12
“Current” - really? All current implementations?  Delete “current” or replace
with “naive” maybe.

p.12
“Communicate directly” - at L2?  If so, why?

p.12
An example of a recommendations section here, where other sections with advice
are not titled as such. See the General comment on this.

p.13
“Trivial” cases - aren’t these common ones, like edge switches in an enterprise?

p.13
Why “hostile”?  Delete?

p.14
In 2.3.5 last para, what about mDNS, Bonjour?   Though the DNS SD work is now
on unicast discovery.

p.21
Maybe add here 802.1x as an example of the value of RADIUS logs, and add in
here as bullets info harvested from switches and (say) router NDP syslog
(though that’s I suppose the 4th bullet).  These are mentioned in 2.6.1.7 but
should be split out at the same level as the other topics here.

p.28
The text is 2.6.2.2 repeats earlier text.
Similarly text in 2.6.2.3 is repeated form before.

p.29
In 2.6.2.4 presumably also a rapid growth in ND cache size is an indicator.

p.29
In 2.7 point to RFC 4942

p.30
Should RFC 6092 be mentioned here?
And that the best defence against IPv6 attacks n “IPv4 only” networks is to
deploy and manage IPv6?

p.31
First bullet on this page - but isn’t this the same as if the traffic is not
tunnelled?  Why does tunnelling add the requirement?  The same applies on the
first para on p.32

p.31
Maybe say here the mitigations can also break tunnel brokers (might be desired,
but users will notice…)…. Maybe tunnels to specific brokers can be allowed.

p.32
ISATAP, in 2021?  Same with 6rd.  General advice should be deploy native, avoid
tunnels.

p.33
Same for 6to4.

p.34
Teredo though, is that still included in Windows and XBoX, as a MS thing?

p.36
Maybe cite Geoff Huston’s blog on this - it’s very good.  Maybe there’s a more
recent update though -
https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/. Host CLAT is
applicable here?  (Hence a site should support the 64PREF RA option?  RFC8781

p.38
In 2.8, to be fair IPv4 is also hardened a lot of late due to the prevalence of
use of devices in WiFi hotspots etc.

p.37
Also RFC6092 on section 3.1?

p.38
“Where RFC1918 address are often used” - add “often”, the text implies all
enterprises use v4 NAT.

p.41
Only 2 normative references?

Nits:

p.1
“The Internet” - you probably mean “an ISP network”
“Describes the security” - delete “the”

p.4
“Which are the switch” delete “which are”

p.8
Varying -> various

p.10
ipv6 -> IPv6

p.18
Router processor - add r to “route”

—
Tim

---

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

Hi Tim,

thanks so much for another detailed look at the draft.
Your feeling that it has been in the making for a while is correct (tell me about it ;-), still we think that the operational security guidance for IPv6 hasn't change much over time, and it might even be more needed than ever (given current momentum of IPv6 uptake).
I went through your below points, and for many of them I've performed according clarifications/enhancements of the draft. A new version has then been uploaded.

Wish you a great weekend

Enno

On Wed, Apr 07, 2021 at 02:12:37AM -0700, Tim Chown via Datatracker wrote:
> processed by the IESG.?? These comments were written with the intent of
> addressed in last call may be included in AD reviews during the IESG review.??
> inevitable ???Frankenstein??? feel to it.  The document would be much better for a
> hosts, address accountability (which isn???t mentioned here?), avoiding
> I don???t understand why NPTv6 is mentioned here, this early.  Just say that some
> Again, NPTv6 is mentioned.  This section is titled ???addressing architecture???
> In the 7934 para, RFC8981 should be mentioned as it???s a significant reason of
> ???Even if the use of DHCP??? - this reads badly.  Rather 8504 talks about this in
> ???Current??? - really? All current implementations?  Delete ???current??? or replace
> with ???naive??? maybe.
> 
> p.12
> ???Communicate directly??? - at L2?  If so, why?
> 
> p.12
> ???Trivial??? cases - aren???t these common ones, like edge switches in an enterprise?
> 
> p.13
> Why ???hostile????  Delete?
> 
> p.14
> (though that???s I suppose the 4th bullet).  These are mentioned in 2.6.1.7 but
> And that the best defence against IPv6 attacks n ???IPv4 only??? networks is to
> deploy and manage IPv6?
> 
> p.31
> First bullet on this page - but isn???t this the same as if the traffic is not
> but users will notice???)???. Maybe tunnels to specific brokers can be allowed.
> 
> p.32
> Maybe cite Geoff Huston???s blog on this - it???s very good.  Maybe there???s a more
> recent update though -
> ???Where RFC1918 address are often used??? - add ???often???, the text implies all
> enterprises use v4 NAT.
> 
> p.41
> ???The Internet??? - you probably mean ???an ISP network???
> ???Describes the security??? - delete ???the???
> 
> p.4
> ???Which are the switch??? delete ???which are???
> 
> p.8
> Varying -> various
> 
> p.10
> ipv6 -> IPv6
> 
> p.18
> Router processor - add r to ???route???
> 
> ???
> Tim
> 
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

-- 
Enno Rey

Cell: +49 173 6745902
Twitter: @Enno_Insinuator

---

From: Warren Kumari <[email-masked]>
Date: Tue, 13 Apr 2021 16:59:31 -0400

Just a quick note to say thanks to Tim for the excellent and detailed
review, and to the authors for addressing it...

I took a quick skim through the diffs, and it was a little tricky for me to
tel which all of the comments had been addressed -- authors, if you get a
chance, could you reply noting which comments were folded into -26?
W

On Sat, Apr 10, 2021 at 2:46 PM Enno Rey <[email-masked]> wrote:

> Your feeling that it has been in the making for a while is correct (tell
> me about it ;-), still we think that the operational security guidance for
> IPv6 hasn't change much over time, and it might even be more needed than
> ever (given current momentum of IPv6 uptake).
> I went through your below points, and for many of them I've performed
> according clarifications/enhancements of the draft. A new version has then
> been uploaded.
>
> Wish you a great weekend
>
> Enno
>
>
>
>

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Tim Chown <[email-masked]>
Date: Wed, 21 Apr 2021 13:41:11 +0000

Hi,

I’ve not yet seen any comments as proposed by Warren, and the review is due (the deadline was a shorter than usual one).  I can go ahead and look to determine the changes from the diff view.

A fairly main point was whether any summary recommendations would be added, given the document’s length, and the variation in style through the document, with some sections having recommendations subsections, others not.  There is a lot of good advice in the text, but it’s a long read as is, and there’s likely a couple of pages of key bullet points that could be added.

When is the draft coming back to the IESG?

Tim

> On 13 Apr 2021, at 21:59, Warren Kumari <[email-masked]> wrote:
> 
> Just a quick note to say thanks to Tim for the excellent and detailed review, and to the authors for addressing it...
> 
> I took a quick skim through the diffs, and it was a little tricky for me to tel which all of the comments had been addressed -- authors, if you get a chance, could you reply noting which comments were folded into -26?
> W
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Apr 2021 11:50:59 -0400

On Wed, Apr 21, 2021 at 9:41 AM Tim Chown <[email-masked]> wrote:

> Hi,
>
> I’ve not yet seen any comments as proposed by Warren, and the review is
> due (the deadline was a shorter than usual one).  I can go ahead and look
> to determine the changes from the diff view.
>
> A fairly main point was whether any summary recommendations would be
> added, given the document’s length, and the variation in style through the
> document, with some sections having recommendations subsections, others
> not.  There is a lot of good advice in the text, but it’s a long read as
> is, and there’s likely a couple of pages of key bullet points that could be
> added.
>

Actually, it is on tomorrow's telechat. Do you think that this is important
enough to hold the document?  Keeping in mind that the document has been
many years in the making...

W

> > I took a quick skim through the diffs, and it was a little tricky for me
> to tel which all of the comments had been addressed -- authors, if you get
> a chance, could you reply noting which comments were folded into -26?
> > W
> >

---

From: Tim Chown <[email-masked]>
Date: Wed, 21 Apr 2021 16:36:27 +0000

> On 21 Apr 2021, at 16:50, Warren Kumari <[email-masked]> wrote:
> 
> Actually, it is on tomorrow's telechat. Do you think that this is important enough to hold the document?  Keeping in mind that the document has been many years in the making...

It’s one of those where were you writing it from scratch, you’d most likely include a short key recommendations section.  But with it having evolved over many years, especially section 2, it’s understandable that it has something of a Frankenstein feel.

But the advice that is in there is good, even when repeated in a few places.  It would do no harm to ship it.  I’m sure the authors would be very happy to see it published :)

I’ll try to check the diffs tonight.

Tim

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 21 Apr 2021 18:36:43 +0000

Tim, Warren,

Replying with only the author hat (and after consultation with my co-authors) on this email after having read Warren's and Tim's replies.

Tim, I do not know whether you remember all the painful journey of this document but the authors do :-) 

a) the early versions of the I-D included a lot of 'recommendation' wording but the OPSEC WG requested us to remove them (this is also the reason why it is not a BCP)

b) getting a summary would be a nice idea but, again, to reach the WG consensus, we had to make some recommendation with restrictions and caveats for special cases (e.g., remember the ULA, RA-guard  discussions ?)... hence, I do not think that this is possibly to make a short summary without including the restrictions/specifics ... so the summary list will be very very long and not very useful

All the other last call comments and the IESG COMMENT points  will be addressed once all feedback is collected,   by either updating the text or explaining our points of view on the comment.

Thank you again for your review and the discussion

Regards

-éric

-----Original Message-----
From: Tim Chown <[email-masked]>
Date: Wednesday, 21 April 2021 at 15:41
To: Warren Kumari <[email-masked]>
Cc: Enno Rey <[email-masked]>, ops-dir <[email-masked]>, "[email-masked]" <[email-masked]>, opsec wg mailing list <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25
Resent-From: <[email-masked]>
Resent-To: Eric Vyncke <[email-masked]>, Kiran Kumar Chittimaneni <[email-masked]>, Merike Kaeo <[email-masked]>, <[email-masked]>, <[email-masked]>, Ron Bonica <[email-masked]>, <[email-masked]>, <[email-masked]>, Gyan Mishra <[email-masked]>, <[email-masked]>
Resent-Date: Wednesday, 21 April 2021 at 15:41

    Hi,

    Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 22 Apr 2021 10:55:36 +0000

Hi,

I’ve checked through -26 and compared as best as I can to -25, and submitted the review.

I’m happy enough to put a ‘Ready’ tag on it.  It could always be better, but at 50 pages, I fully understand why shipping it is desirable.  I can’t see anything specifically wrong in the text :)

Tim

> On 21 Apr 2021, at 19:36, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
> Tim, Warren,
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 22 Apr 2021 11:11:32 +0000

Thank you Tim for the re-check of the document.

Regards

-éric

-----Original Message-----
From: Tim Chown <[email-masked]>
Date: Thursday, 22 April 2021 at 12:55
To: Eric Vyncke <[email-masked]>
Cc: Warren Kumari <[email-masked]>, Enno Rey <[email-masked]>, ops-dir <[email-masked]>, "[email-masked]" <[email-masked]>, opsec wg mailing list <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25
Resent-From: <[email-masked]>
Resent-To: Eric Vyncke <[email-masked]>, Kiran Kumar Chittimaneni <[email-masked]>, Merike Kaeo <[email-masked]>, <[email-masked]>, <[email-masked]>, Ron Bonica <[email-masked]>, <[email-masked]>, <[email-masked]>, Gyan Mishra <[email-masked]>, <[email-masked]>
Resent-Date: Thursday, 22 April 2021 at 12:55

    Hi,

    Tim