Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25

[Tim Chown <[e-mail]>]

Hi Enno,

Your comments and responses are all fine, thank you for explaining the rationales.   Hopefully the new version will be approved for publication soon, it will be very useful for the community.

Best wishes,
Tim

> On 10 May 2021, at 09:08, Enno Rey <[e-mail]> wrote:
> 
> Hi Tim,
> 
> thanks again for the review, for your support during the different stages of its development, and for the detailed comments.
> 
> We have incorporated most of the comments that we felt were in line with the general document and were agreed upon by the authors. Some comments were not acted upon though as the current text is the result of WG consensus, and/or a proposed change would have modified the overall direction of a specific recommendation.
> Please allow to comment/address them in the following.
> 
> 
> On Wed, Apr 07, 2021 at 02:12:37AM -0700, Tim Chown via Datatracker wrote:
>> 
>> 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.
> 
> A mention of EHs was added (good point, thank you). As for NPTv6 part we decided to leave as is.
> 
> 
>> 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?
> 
> We removed the part referring to multi-homed networks (and the 'exception' piece as a whole as it could indeed be a bit confusing).
> 
> 
>> 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.
> 
> We simplified the section title to just 'Addressing' to reflect the general nature of the recommendations.
> 
> 
> 
>> p.4
>> In the 7934 para, RFC8981 should be mentioned as it???s a significant reason of
>> devices having more addresses.
> 
> An explicit reference to RFC 8981 as one of the main reasons for multiple addresses was added.
> 
> 
> 
>> p.5
>> ULAs are also useful where the prefix changes, for stable internal addressing
>> as the global prefix changes?  Typically in residential networks.
> 
> From our perspective the text already mentions this scenario.
> 
> 
>> p.5
>> Section 2.1.4 is really about choices in address assignment within a network.
> 
> We feel that it's mostly about the various implications of stable addresses, which is why we stayed with the current section title.
> 
> 
>> 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.
> 
> 
> RFC 7707 has a section on mitigations, which is why we point to that one.
> 
> 
>> p.6
>> All mentions of 4941 should be replaced with 8981.
> 
> 
> done ;-)
> (This was one of cases where parallel publications obsoleted an item in our document, due to the long time of document development, as you rightfully stated)
> 
> 
>> p.7
>> Can use 7721 and 8981 together.
> 
> We decided to leave as is.
> 
> 
>> p.7
>> Why are DHCP and DNS limped together?  The DNS is only about DNSSEC, so call it
>> that?
> 
> We split this part into two individual sections on DHCP and DNS each.
> 
> 
>> 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.
> 
> The "even if the use" part was removed in the course of the rewrite/-ordering of the section.
> 
> 
> 
>> 
>> p.8
>> The first para is very muddled.
> 
> We performed a number of clarifying changes in this part of the document. We hope they address this one, too.
> 
> 
>> 
>> 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.
> 
> Good point; a respective sentence was added.
> 
> 
>> 
>> 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.
> 
> We decided not to rewrite these parts.
> 
> 
>> 
>> p.10
>> In 2.2, the intro can say these issues have parallels in IPv4.
> 
> We decided not to rewrite the intro.
> 
> 
>> 
>> p.11
>> First line, say the attack can typically happen from a large address scan if
>> permitted into the network?
> 
> That's correct. Still, as we point to RFC 6583 for an extensive discussion, we felt this addition wouldn't be needed here.
> 
> 
>> 
>> p.11
>> Bullet 1 - that contradicts the comments on predictable addressing.
>> Bullet 2 - how?  Some clues here would be useful.
> 
> We added some some examples to the second bullet.
> 
> 
>> 
>> p.12
>> ???Current??? - really? All current implementations?  Delete ???current??? or replace
>> with ???naive??? maybe.
> 
> The wording was modified in order to avoid 'current'.
> 
> 
>> 
>> p.12
>> ???Communicate directly??? - at L2?  If so, why?
> 
> Wording was clarified, together with an example.
> 
> 
>> 
>> 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.
> 
> Please see Eric's e-mail from April 21 why we couldn't follow that path (based on previous WG discussion).
> 
> 
>> 
>> p.13
>> ???Trivial??? cases - aren???t these common ones, like edge switches in an enterprise?
> 
> The section was modified in order to provide more clarification.
> 
> 
>> 
>> p.13
>> Why ???hostile????  Delete?
> 
> We deleted 'hostile' in the context of the distribution of a DNS resolver.
> 
> 
>> 
>> p.14
>> In 2.3.5 last para, what about mDNS, Bonjour?   Though the DNS SD work is now
>> on unicast discovery.
> 
> That's a tricky one as we've seen differing approaches here (mDNS/Bonjour), based on different operational needs.
> Still we added mentions of mDNS and LLMNR.
> 
> 
>> 
>> 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.
> 
> Some more potential log sources were added. Besides that we felt that the overall section should be left as is.
> 
> 
> 
>> 
>> p.28
>> The text is 2.6.2.2 repeats earlier text.
>> Similarly text in 2.6.2.3 is repeated form before.
> 
> Agreed, but these sections might be selectively read by specific audiences which is why we accepted a bit of redundancy here.
> 
> 
>> 
>> p.29
>> In 2.6.2.4 presumably also a rapid growth in ND cache size is an indicator.
> 
> Good point & worthwhile suggestion; we added that one.
> 
> 
> 
> 
>> 
>> p.29
>> In 2.7 point to RFC 4942
> 
> A respective reference was added.
> 
> 
>> 
>> 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?
> 
> Let's hope that this document comes into play exactly when IPv6 gets deployed in a properly managed way ;-)
> 
> 
> 
>> 
>> 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
> 
> 	
> As there had been a lot of discussions in the WG about the whole tunneling part of the document, we considered this part as aligned with WG consensus, and hence refrained from significant changes here. This applies to most of your comments in this part (still some quick notes on individual technologies in the following).
> 
> 
> 
>> 
>> 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.
> 
> 	
> See the above general comment (on the tunneling piece of the document) from our perspective.
> 
> 
> 
>> 
>> p.32
>> ISATAP, in 2021?  Same with 6rd.  General advice should be deploy native, avoid
>> tunnels.
> 
> I think we'd all be happy if ISATAP wasn't a thing in 2021 anymore. Alas, it seems more prevalent than one might think, e.g. see this recent talk from the PAM conference (April 2021):
> https://www.youtube.com/watch?v=_c061S5iZfo. We also added a reference to the full paper.
> 
> 
> 
>> 
>> p.33
>> Same for 6to4.
> 
> See comment on ISATAP
> 
> 
>> p.34
>> Teredo though, is that still included in Windows and XBoX, as a MS thing?
> 
> Yep, still supported/deployed with the Xbox.
> 
> 
> 
>> 
>> 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
> 
> Agree that Geoff's blog is excellent, but we decided not to perform changes here.
> 
> 
> 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.
> 
> Agree. 
> 
> 
>> 
>> p.37
>> Also RFC6092 on section 3.1?
> 
> 3.1 already had a reference to RFC 6092.
> 
> 
>> 
>> p.38
>> ???Where RFC1918 address are often used??? - add ???often???, the text implies all
>> enterprises use v4 NAT.
> 
> Done. You're right about the misleading implication of the old text.
> 
> 
>> 
>> p.41
>> Only 2 normative references?
> 
> Due to nature of the document we feel that the informative ones are more important (and we actually performed some slight changes to the references, e.g. adding the ISATAP paper mentioned above).
> 
> 
> 
> 
>> 
>> Nits:
>> 
> 
> All the nits have been addressed, too.
> 
> 
> I wish everyone a great week
> 
> Enno
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Enno Rey
> 
> Cell: [phone]
> Twitter: @Enno_Insinuator