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

["Smith, Donald" <[e-mail]>]

Before approval, all the URIs should be checked, for example the cymru link is broken.

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

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.


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]."

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)?


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
[e-mail]

________________________________________
From: OPSEC [[e-mail]] on behalf of Tim Chown [[e-mail]]
Sent: Monday, July 02, 2018 11:52 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13

Reviewer: Tim Chown
Review result: Not Ready

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?

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.

There are many typos and grammatical errors throughout the document.

Specific comments:

p.3

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

Do we need to mention NPTv6 here?

p.4

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

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

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

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

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!

Para 2 - or do both!

p.6

Section 2.1.3 - and ND cache exhaustion protection

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.

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.

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.

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

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.

p.9

Section 2.2.4 - worth adding RFC 8221 and RFC 8247?

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?

p.10

Spurious DHCP-Shield wording at end of para 2.

Section 2.3.2 - mention ND cache exhaustion

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?

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

p.12

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

p.13

A lot of text on something hardly used?

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

p.16

Replace RFC 2460 with RFC 8200?

p.17

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

p.20

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

Value in mentioning RFC 8096?

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

p.21

And RESTCONF?

Windows 7?

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

p.22

"era" again.

Mention DHCPv6 anonymity profiles - RFC 7844

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.

p.24

Mostly duplicating RFC 7077.

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

p.26

Perhaps be consistent with rather than maintain parity?

p.29

6to4...?

p.31

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

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?

p.35

last para - better to omit, I think?


_______________________________________________
OPSEC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsec
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.