Subject: Re: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 8 Feb 2021 15:50:41 +0000

Hello Tim,

Better very late than never… Having some time this week to make some progress on this I-D... I hope to publish a -22 before the IETF-110.

Some comments on the outdated review are prefixed with EV>

Thank you for your review :-)

-éric

-----Original Message-----
From: Tim Chown <[email-masked]>
Date: Monday, 2 July 2018 at 19:52
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13

    Hi,

    I have reviewed this document 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.

    The document is Not Ready for publication.

    General comments:

    The draft is well written, and the authors are clearly experts in the area, but
    the evolution of 13 versions of the draft since WG adoption in 2012 means the
    draft is somewhat disjoint, and has a number of sections where current best
    practices and related RFCs are not included.  A prime example is in the area of
    address configuration.

    There are seven pages on transition technologies; might that be better homed in
    a -bis of RFC 4942?

EV> we tried to be exhaustive and gather all (?) references in this single document even at the expense of 7 pages.

    The sections on control plane and routing (2.4, 2.5) are somewhat generic to
    IPv4 and IPv6; there is very little IPv6-specific information in there. While
    this isn't bad per se, it pads the length of the document somewhat without much
    new material.

EV> agreed, I have added a preamble with your warning and pointing to the difference between IPv4 and IPv6 but keeping the section as it contains many valuable reference (IMHO).

    There are many typos and grammatical errors throughout the document.

EV> with not a single author being native English speaker no wonder... The document will go through a spell checker.

    Specific comments:

    p.3

    "subtle differences between IPv4 and IPv6" - I don't think L2 vs L3 resolution,
    ND vs ARP, is that subtle?

EV> changed into "subtle but critical and important differences "

    Do we need to mention NPTv6 here?

EV> added

    p.4

    Mention 6renum and the gaps draft it produced (RFC 7010)?

EV> added

    The recommendation to use PI for a larger network implicitly means no NPTv6?

EV> the text has been modified in more recent versions.

    Any value in adding a note about the size of prefix an ISP offers?  (6177, etc)
     That affects how the network is configured.

EV> indeed, good catch !

    Where is topology discovery / probing mentioned?  Cite RFC 4864?

EV> the 'scanning' reference is probably enough as it is and this section has heavily been reworded.

    p.5

    I think the phrase in para 1 is "security by obscurity".  I would argue that
    that can complement other security, but must not be depended upon!

EV> added (even if it is mostly obvious)

    Para 2 - or do both!

    p.6

    Section 2.1.3 - and ND cache exhaustion protection

EV> not changing the section title to be consistent with the other section titles. The newer text is also clear on the ND cache issue.

    Section 2.1.4 - "Normal" SLAAC no longer relies on EUI-64 from MAC addresses -
    now RFC 8064 recommends the RFC 7217 version of SLAAC.

EV> the whole section is indeed completely rewritten now

    This whole section is written in a jumbled order.

    There should be a separate section on address accountability - whether it's
    needed in a given scenario, and where it is, how best to achieve it - there's
    bits of this scattered around in many places, but it's independent of privacy
    addressing.

    Para 3 - see section 2.1.7.

    p.7

    first line - you can't always control managed vs unmanaged of course; a
    university eduroam WiFi is unmanaged, generally, where admin systems probably
    are managed.

EV> this while section has been rewritten, so, some comments do not apply anymore

    second para - these are just hints; and for a host not supporting DHCPv6, it
    gets no address at all.  Perhaps also mention SAVI here.

    Section 2.1.6 - Should mentioned DHCPv6 anonymity profile - RFC 7824 and RFC
    7844.  RFC 7934 suggests not using DHCPv6 in certain circumstances as a result.
     Also RFC 7077 recommends to not issue DHCPv6 addresses sequentially from a
    small pool.

EV> modified (thank you for the references)

    Section 2.1.7 - note RFC 8273 is designed for shared environments, and
    isolation is a primary goal; add reference to RFC 7934.

EV> the latest intro to section 2.1 has such a text

    p.8

    Perhaps check against text in draft-ietf-6man-rfc6434-bis-08 in section 5.2,
    and the excessive EH option processing text in 5.3 there.

EV> added reference to RFC 8504

    p.9

    Section 2.2.4 - worth adding RFC 8221 and RFC 8247?

EV> I do not think so as those are really generic and not linked to IPv6 (and I know that control plane/routing are mostly identical but they are at least some differences)

    Section 2.3 - split out the NS/NA messaging here from ND in general, else you
    should include SLAAC.  Given you discuss SLAAC later, focus on NS/NA here in
    its own subsection?

EV> flow has changed based on your comment

    p.10

    Spurious DHCP-Shield wording at end of para 2.

EV> fixed

    Section 2.3.2 - mention ND cache exhaustion

EV> done

    p.11

    Rate limit also on ICMP messages?

    Perhaps separate out the power drain issue as a threat?  RFC 7772 is relevant
    here.

    The two drafts cited here by thubert and chakrabarti died in 2012 and 2015
    respectively?   Maybe RFC 6775 instead?

EV> indeed! Done

    Section 2.3.3 - or just supply a 'bad' DNS resolver address

EV> added

    p.12

    After para 3 emphasise still need RAs in a DHC environment for default router
    and on-link prefix(es)

EV> indeed, added
    p.13

    A lot of text on something hardly used?

EV> let's leave the SeND text here anyway for archival __

    p.14 - 20
    Lots of generic text applicable to IPv4 too?

EV> true of course, added preamble to state the congruence but also pointing to the differences

    p.16

    Replace RFC 2460 with RFC 8200?

EV> left the reference but added text about 8200

    p.17

    There is now draft-ietf-6man-rfc6434-bis-08

EV> even RFC 8504 now __ but the text has been heavily modified anyway

    p.20

    What's required to differentiate logging of different IP versions?

EV> added text rfcaround ipVersion from IANA

    Value in mentioning RFC 8096?

EV> I do not think so

    Or YANG modules (as per Section 16 of draft-ietf-6man-rfc6434-bis-08)

EV> more recent versions have already this text __

    p.21

    And RESTCONF?

EV> see above

    Windows 7?

EV> just a data point... at the time of writing

    At bottom, "was usually done in the IPv4 era" -> "is commonly used in IPv4
    networking"

EV> possibly better wording

    p.22

    "era" again.

EV> done
    Mention DHCPv6 anonymity profiles - RFC 7844

EV> mentioned earlier

    P.23

    Forensics - that's *one* way - can e.g. use a NMS; one that harvests network
    device data via SNMP; many open source options available.

EV> text has changed in more recent versions

    p.24

    Mostly duplicating RFC 7077.

EV> or making a short summary of RFC 7077 ;-)

    Section 2.6.2.3 - rfer to RFC 5952, or se Sec 2.6.1.1

EV> text has changed in more recent versions

    p.26

    Perhaps be consistent with rather than maintain parity?

EV> better wording indeed

    p.29

    6to4...?

EV> I know... current versions clearly identify 6to4 as historic

    p.31

    Last para is very handwavey!  Device OSes are more secure these days to work in
    IPv4 hotspots too?

EV> text has shrinked and should be less handwavey

    p.33

    A campus enterprise is different - BYOD vs managed, esp. wifi/eduroam, or
    Science DMZ networks; perhaps mention RFC 7381, esp. sections 2.4, 3.2 and 4.1?

EV> of course, our very own RFC 7381 __, done

    p.35

    last para - better to omit, I think?

EV> I am afraid so... it was a nice idea though

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 8 Feb 2021 15:51:01 +0000

Hello Donald,

As for Tim Chown's review, here is my belated reply...

Look for EV>

Thank you for the review

-éric

-----Original Message-----
From: "Smith, Donald" <[email-masked]>
Date: Monday, 2 July 2018 at 22:14
To: Tim Chown <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13

    Routing security talks exclusively to OSFPv3 which isn't in common use externally today, BGP would be a better choice.

EV> I made the reference to RFC 7454 more prominent in the text

    2.1.1 This:
    There are many scanning
       techniques and more to come possible, hence, operators should never
       relly on the 'impossible to find because my address is random'
       paradigm.

    Should probably be this:
    There are many scanning techniques and possibly more to come, hence, operators should never rely on the 'impossible to find because my address is random' paradigm.

    Or adding Tom's suggestion:
    There are many scanning techniques and possibly more to come, hence, operators should never rely on the 'security by obscurity' paradigm.

EV> indeed, the text has changed following Tim's suggestion

    Maybe it doesn't belong there but this appears to be a potential new smurf amplification vector.

    "Another way works only for local network, it consists in sending a
       ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which
       is all IPv6 nodes on the network.  All nodes should reply to this
       ECHO_REQUEST per [RFC4443]."

EV> except that this is local only (packets to ff02::1 will not be forwarded by an IP router). SO, the attack is local only (but could be a real annoyance in same settings).

    But maybe that belongs in 4443 or some other draft?

    I feel some mention of anycast used for DDoS Reflection and Amplification (RA) should be included (again might be out of scope)?

EV> I agree that RFC 4443 did not take this amplification attack into consideration. At least nowadays, large layer-2 (notably wifi) have disabled the link-local multicast. Added a new section 2.3.6 on this issue.

    Metric System < +000 > -000
    Extra People's Terribly Good Meals Kept mY uNCLE    Ned   Purring For     Ages
    Exa   Peta        Tera     Giga   Mega  Kilo milli Micro(u) Nano Pico    Femto Atto
    [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Sun, 14 Feb 2021 15:55:18 +0000

Hi Eric,

> On 8 Feb 2021, at 15:50, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
> Hello Tim,
> 

Good luck with that!

> Thank you for your review :-)

The rewritten sections look a lot better.  Everything you’ve said below inline seems ok, but I guess we’ll be re-reading the fine final draft soon?

> EV> we tried to be exhaustive and gather all (?) references in this single document even at the expense of 7 pages.

Fair enough, and a -bis of 4942 could be another epic undertaking!

> EV> the text has been modified in more recent versions.

Seems a good compromise, though invariably contentious.

> EV> let's leave the SeND text here anyway for archival __

I guess so, but that “over a decade” since specification is soon two decades :)

Best wishes,
Tim