Thank you Tim for the re-check of the document.
Regards
-éric
-----Original Message-----
From: Tim Chown <tim.ch...@jisc.ac.uk>
Date: Thursday, 22 April 2021 at 12:55
To: Eric Vyncke <evyn...@cisco.com>
Cc: Warren Kumari <war...@kumari.net>, Enno Rey <e...@ernw.de>, ops-dir
<ops-...@ietf.org>, "last-c...@ietf.org" <last-c...@ietf.org>, opsec wg mailing
list <opsec@ietf.org>, "draft-ietf-opsec-v6....@ietf.org"
<draft-ietf-opsec-v6....@ietf.org>
Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25
Resent-From: <alias-boun...@ietf.org>
Resent-To: Eric Vyncke <evyn...@cisco.com>, Kiran Kumar Chittimaneni
<kk.chittiman...@gmail.com>, Merike Kaeo <mer...@doubleshotsecurity.com>,
<e...@ernw.de>, <furr...@gmail.com>, Ron Bonica <rbon...@juniper.net>,
<war...@kumari.net>, <rwil...@cisco.com>, Gyan Mishra <hayabusa...@gmail.com>,
<hayabusa...@gmail.com>
Resent-Date: Thursday, 22 April 2021 at 12:55
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) <evyn...@cisco.com> wrote:
>
> 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 <tim.ch...@jisc.ac.uk>
> Date: Wednesday, 21 April 2021 at 15:41
> To: Warren Kumari <war...@kumari.net>
> Cc: Enno Rey <e...@ernw.de>, ops-dir <ops-...@ietf.org>,
"last-c...@ietf.org" <last-c...@ietf.org>, opsec wg mailing list
<opsec@ietf.org>, "draft-ietf-opsec-v6....@ietf.org"
<draft-ietf-opsec-v6....@ietf.org>
> Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25
> Resent-From: <alias-boun...@ietf.org>
> Resent-To: Eric Vyncke <evyn...@cisco.com>, Kiran Kumar Chittimaneni
<kk.chittiman...@gmail.com>, Merike Kaeo <mer...@doubleshotsecurity.com>,
<e...@ernw.de>, <furr...@gmail.com>, Ron Bonica <rbon...@juniper.net>,
<rwil...@cisco.com>, <war...@kumari.net>, Gyan Mishra <hayabusa...@gmail.com>,
<hayabusa...@gmail.com>
> Resent-Date: Wednesday, 21 April 2021 at 15:41
>
> 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 <war...@kumari.net> 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
>>
>> On Sat, Apr 10, 2021 at 2:46 PM Enno Rey <e...@ernw.de> wrote:
>> 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:
>>> 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
>>>
>>>
>>> _______________________________________________
>>> OPSEC mailing list
>>> OPSEC@ietf.org
>>> https://www.ietf.org/mailman/listinfo/opsec
>>
>> --
>> Enno Rey
>>
>> Cell: +49 173 6745902
>> Twitter: @Enno_Insinuator
>>
>>
>> --
>> The computing scientist’s main challenge is not to get confused by the
>> complexities of his own making.
>> -- E. W. Dijkstra
>
>
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
