Re: [v6ops] Asking for a review of draft-ietf-opsec-v6-08

["Howard, Lee" <[e-mail]>]

I have done a thorough review of this document (even as it was updated from –8 to –09, so the relevance of my comments may change partway through. I did take a long time, but it's because I think this document is relevant and it should be very good and readable to make it as useful as possible.

Notes below.

Lee

--

This is listed as Informational, but in some places is recommending best practice. Is this really intended to be a BCP? I always feel strange seeing RFC2119 boilerplate and language in an Informational document. For instance, 2.1.4 says, “It must be noted that.”  That’s not an RFC 2119 use of “must,” despite what 1.1 says.  But 2.3.5 says “prefix must not be used for on-link determination.” Not sure if that’s good advice or refers to a 3GPP specification, so it’s unclear.

I think the tone suggesting IPv6 is new is misplaced. This starts right in the abstract, but RFC 4942 was published 9 years ago. Maybe change it to, “Some of the security challenges in IPv6 are different than those in IPv4.”

The Introduction continues the theme that IPv6 is new. It also doesn’t say much by way of introducing the document.  Cut the first two paragraphs.


Section 2 title should probably be “General Security Considerations” not “Generic Security Considerations”

I’d like to see some description of why it’s hard to renumber. A pointer to at least RFC6866, and maybe RFC6879 and RFC7010. You could mention ongoing work in SUPA or ANIMA, but don’t have to. The most relevant note in renumbering is rfc6866 2.8, that ACLs (and by extension, firewall rules) need to be updated.

You don’t say anything in 2.1 about using bits for functional purposes. You say that geographic boundaries are good for simplifying security policies (and I agree, and wish it were appropriate to note that an ACL can go from 200 lines grown organically over a decade in IPv4 to 4 lines with an IPv6 address plan designed for growth), but it can be useful to have, say, a management network be a specific subnet out of the regional supernets. x:y:z:666::/48, for instance. Or do you disagree?

We could debate the role of law enforcement, but I’d like to reword:
However, one aspect to keep in mind is who has ownership of the
   address space and who is responsible if/when Law Enforcement may need
   to enforce restrictions on routability of the space due to malicious
   criminal activity.

To
The point of contact listed in public registries is the one who will have to respond to legal inquiries, and potentially take action as required by legal authority.

In 2.1.1, it would be nice to acknowledge the different kinds of nodes, and where static addresses make sense. Servers are different from workstations or residential users. Routers and firewalls have different considerations. What about printers? Should IP phones be numbered the same way as desktops?

2.1.2 says
The implicit expectation from the RFC is that all ULAs
   will be randomly created as /48s.  Any use of ULAs that are not
   created as a /48 violates RFC4193<https://tools.ietf.org/html/rfc4193> [RFC4193<https://tools.ietf.org/html/rfc4193>].

These two sentences are strange. Is it implicit or explicit?  If it’s implicit, can you explain how RFC 4193 implies that?  If it’s only implied, then is it a violation?  I think these two sentences should be rewritten, and you don’t need both of them.

LLA can only replace ULA for a single subnet.

Although ULAs are supposed to be used
   in conjunction with global addresses for hosts that desire external
   connectivity,
[citation needed]

“ULAs in conjunction with some sort of address translation”  Please cite rfc6296. You might also want to include reference to its Security Considerations section, and in fact your own discussion of perimeter security in paragraph 2 of 2.1.1.

“(the authors of this document do not share this point of view)” isn’t really appropriate commentary in a WG document. For this to be IETF stream, it needs to reflect consensus.

So, knowing that ULAs are a thorny nest in a rathole, I suggest:
 Unique Local Addressing (ULA, [RFC 4193]) is “globally unique and is intended for local communications” [RFC 4193].  ULAs could be used for systems that do not require Internet connectivity, such as a management network, or back-end servers, as long as software updates can be done locally. On a single subnet, Link-Local Addresses (LLA, [RFC 7404]) can be used instead. Some cases may be covered by privacy extensions; see section 2.1.4 below.

ULAs can be used with Network Prefix Translation (NPT66, [RFC6296]) to reach the Internet while hiding infrastructure addresses. However, since this is a 1:1 mapping of inside and outside addresses, it does not provide the same level of obscurity as NAPT44 [RFC?]; the Security Considerations section of [RFC 6296] provides a good description. The use of good perimeter security controls (stateful firewall rules, logging [RFC6302]) provides better security than address translation.  (note: discussion of difference between NAPT44 and stateful firewall would be fine here, if you can’t find another document to reference)

In 2.1.3 change:
            The operational disadvantages need also to be carefully considered RFC7404
To
            The operational caveats described in [RFC7404] need to be carefully considered.

In 2.1.4, I don’t understand how privacy extensions “reduce the attack exposure window.” Do you mean that if an IP address is targeted, a node only uses that address for (default) 24 hours? Or do you mean fewer ports are exposed? What kind of window do you mean?

I think “malevolent” is the wrong word. “Malevolent” means wishing evil upon a person: bad will. “Malicious” means intending to do evil. “Malevolent” is more like hatred, which may or may not include action. “Malicious” is an intent to do harm; therefore, bad actors participate in “malicious activities.” However, since you then say, “(whether on purpose or not)” neither one is the right word. It took me several times reading, but I think you mean:

As privacy extension addresses could also be used to obfuscate (intentionally or unintentionally) malicious or prohibited activities, it is important to disable SLAAC and rely on DHCPv6 in scenarios where user attribution is important.

However, as was pointed out in objection to dhcpv6-slaac-problem, DHCPv6 doesn’t provide a better record; if you want attribution, you need to log ND.

The following sentence is a grammatical wreck.
However, in scenarios where anonymity is a
   strong desire since protecting user privacy is more important than
   user attribution, privacy extension addresses should be used

Propose:
            However, in scenarios where protecting user privacy is more important than user attribution, privacy extension addresses are more appropriate.

The reference to rfc7217 should come earlier in the section, since all considerations for privacy extensions apply to those addresses too.

2.1.5 is true, but I think the document would be more usable if you gave at least of hint of what readers will find in Appendix A of RFC7217 and in RFC772.  Suggest:
However, there are several privacy issues still present with
   [RFC4941<https://tools.ietf.org/html/rfc4941>] such as host tracking, and address scanning attacks are
   still possible.  Details on mechanisms for forming interface identifiers are provided in Appendix A. of [RFC7217]<https://tools.ietf.org/html/rfc7217#appendix-A>, [RFC7721<https://tools.ietf.org/html/rfc7721>] describes security and privacy considerations in depth for several mechanisms used to generate IPv6 addresses.

2.1.6 “audibility” should be “auditability”

“DNS is often used for malware activities” makes it sound like it’s an attack vector that should be shut down.  Also, why is DNS discussed under “Addressing Architecture”?

2.2 isn’t even written. Don’t ask for review until you finish writing your document.

2.3.1 “generic operating systems”  Do you mean SeND isn’t supported in routers, or in hosts?

2.3.2 Shouldn’t “Securing DHCP” be under 2.1.6 “DHCP”? Or should 2.1.6 be here?

Formatting error creates confusion:
threats against DHCP are discussed in the security
   considerations section of RFC3315<https://tools.ietf.org/html/rfc3315> [RFC3315<https://tools.ietf.org/html/rfc3315>]DHCP-shield

   RFC7610<https://tools.ietf.org/html/rfc7610> [RFC7610<https://tools.ietf.org/html/rfc7610>] specifies a mechanism for protecting hosts

2.3.3 I think ND/RA vulnerability is a main section, with Rate Limiting and Filtering as subsections.


 2.3.5  This section is educational for me.
I’m confused about “the advertised /64 on the link” if there’s only LLA. Is there an advertised GUA? Does it make sense to reword this?
The GGSN/PGW never
   configures a non link-local address on the link using the advertised
   /64 prefix on it.
To
The GGSN/PGW never configures anything other than a non link-local address on the link.

“There is no need for address resolution…” could be specifically “address resolution through Neighbor Discovery…”

Still confused. The GGSN/PGW assigns a GUA to the LLA link?  Or a ULA? Or some other scope of “unique”?  And it’s assigned to a link that uses only LLA?

2.4 Thanks for including the definition of “control plane” here, but since it’s quoted, would you use blockquote format? That way I’ll know when the quote ends and original text begins.

I think you mean “general purpose processor” rather than “generic processor.” I read “generic” and think you mean it has no brand name attached, but I think you mean it’s not custom silicon, even if it’s made by Intel, Broadcom, Qualcomm, or whatever.

Two mitigation techniques are given for control plane protection (neither of which is specific to IPv6, btw), but I’m not clear on how they are to be implemented. How do I identify “non-legit control plane packet[s]” in an ACL? Is that what section 2.4.1 is? Can you give guidance on rate limiting? Is there guidance on protocol-specific protection for each of these protocols?

2.4.2
Please reword:
(for example, permit TCP 22 and drop all
      when only SSH is used)
to
(e.g., to allow SSH only, permit TCP 22 and drop all others)

I like the example of the NOC prefix. In fact, I think this is a security advantage of IPv6, since the address architecture may be much cleaner, so you can write an ACL to match security policy in just a line or two of ACL, instead of hundreds. But I’m not sure that’s worth saying.


2.4.3 This section is very frustrating (not the authors’ fault):
The only protection for the RP is to limit
   the rate of those packet exceptions forwarded to the RP, this means
   that some data plane packets will be dropped without any ICMP
   messages back to the source which will cause Path MTU holes.  But,
   there is no other solution.

Is it possible to do more advanced queueing, to rate limit only HBH packets, or to dequeue based on source address (so that an attacker gets no more time on the RP than anyone else)? It might not be; either because attacks tend to be distributed anyway, or because the overhead of that much analysis would offset the protection it would provide. At worst, could you say instead, “There is no known current solution; this is an area for future work.”?

2.5.1
missing close parenthesis:

(which obsoletes RFC6506<https://tools.ietf.org/html/rfc6506> [RFC6506<https://tools.ietf.org/html/rfc6506>]

There are two long paragraphs on OSPFv3, but no specific discussion of any other routing protocols. Is any of this specific to IPv6?

2.5.2
No recommendations? Suggestions for future work?
Risks? I mean, two peers on a point-to-point link have limited exposure. Peers with multihop or using virtual connections have greater exposure.

2.5.3
A link to RFC6890, maybe with commentary, would be welcome in the discussion of reserved prefixes.

2.6.1 These sections feel a little light on what should be logged and why. Oh, now I see that “why” is covered in 2.6.2.

2.6.1.1 Redundancy in the second paragraph

2.7 “some text”?

2.7.2
“To mitigate bypassing of security policies” might better be, “To prevent bypassing security policies, whether implemented on a firewall or just a layer 4 ACL,”

2.7.2.1 “traffic interception ad tunnel injection” should be “and”

2.7.2.2 “and and”

2.7.2.3 “block all UDP outbound traffic”
That doesn’t seem a bit draconian? There are lots of applications that use UDP, and many of them use it specifically to get around firewalls. Games, RTP, QUIC, . . .

2.7.2.8 I think I said this before, but RFC 2119 “MUST” isn’t really appropriate in an Informational document, or even a BCP. RFC 2119 says it’s for specifications, to ensure interoperability.

4.1 Back in 2.5.1 you had discussion of OSPFv3. Are there any BGP notes in 4.1 that would apply there, in the control plane section?

4.3  You say lawful intercept can target “single host (a /128 target)” but if the client is using privacy extensions, that will not be enough detail.



________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.