[privacydir] privacydir review of draft-ietf-savi-threat-scope

["Richard L. Barnes" <[e-mail]>]

Do not be alarmed.  I have reviewed this document as part of the privacy directorate's ongoing effort to some IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other review comments.

This document attempts to scope the threats that the SAVI mechanisms are intended to counter, and describe some potential approaches to countermeasures.  While the document is quite thorough in its descriptions of spoofing problems and concerns related to network architecture, it reads more as a primer on spoofing and anti-spoofing than a set of constraints for a working group.  This expanded focus leaves the document with at least some serious problems: 
(1) It fails to scope the SAVI problem tightly enough, leaving the door open to potentially privacy-risky designs, 
(2) It does not address some solution approaches that would be more privacy-friendly.
(3) It conflates anti-spoofing with attack mitigation/forensics, a much more privacy-risky activity


1. 

With regard to scoping: The document discusses several points in the network architecture (Figure 1) where anti-spoofing measures can be enforced, but it never states clearly at which points the SAVI mechanism is intended to be applied.  Given the considerations discussed in the document (and indeed the SAVI charter), it seems clear that there are sufficient mechanisms (BCP 38 and uRPF) for use at the various inter-network interfaces and, by extension, to links between subnets within a network.  

Thus, the document should clearly state that SAVI is limited to spoofing within a local layer-2 network, before it reaches a router.  The closest the current version comes to this is the statement in Section 4.2.3 that "Much of the work of SAVI is initially targeting minimizing source address spoofing in the LAN."  This statement should be tightened (e.g., by removing "Much" and "initially") and made more prominent as a constraint for the SAVI solution.  

This constraint is important from a privacy perspective because of the risk that SAVI solutions will increase the propagation of potentially private host identity information (e.g., the MAC-IP bindings prevented by RFC 4941).

Another ambiguity that raises privacy concerns is the document's discussion of binding anchors. The document uses the phrase "binding anchor" without definition.  Another SAVI document (draft-ietf-savi-framework, which is not referenced) defines    a binding anchor as a "link layer property of the host's network attachment ... [which] must be verifiable in every packet that the host sends, and harder to spoof than the host's IP source address itself".  

This documents suggests that network authentication credentials, e.g., those used for 802.1X, could be suitable binding anchors.  This proposal clearly contradicts the cited definition for binding anchors, since these credentials are not verifiable in packets.  The use of such credentials outside of their role in AAA systems clearly creates privacy risks by increasing the exposure of what is often personally-identifying information.


2. 

All of the attacks listed in Section 3 rely on a host accepting and processing spoofed packets, as opposed to spoofed packets being used to overwhelm some network-internal resources.  This property would seem to indicate that the real goal for SAVI is the following: A host must not accept packets from other hosts on the same local network unless the source host has been properly assigned that address.

Viewed from this perspective, SAVI should essentially constitute a mechanism for adding assurance to ARP/ND caches, e.g., by allowing hosts to receive information about address bindings either from each other or from an authoritative source such as a router on the link.  By basing the solution at end hosts, where the information being assured already resides, the solution could avoid the privacy concern that the current network-based approaches raise.  Namely, network-based solutions leak information cached in the local network into other parts of the network control plane, increasing the risk that it will be further exposed.   


3.

The document mentions several times the need for greater traceability in support of attack forensics, i.e., for mechanisms that allow network administrators to identify the source of an attack.  These requirements should be removed, because they are out of scope and create privacy risks.

Anti-spoofing mechanisms are a limited subset of traceability mechanisms.  They support attack mitigation/forensics by ensuring that the view of the network from DHCP lease tables and ND caches is correct.  More general traceability mechanisms can involve binding addresses to other data like network access credentials and user identifiers.  These data are not required for anti-spoofing, and are clearly much more privacy-sensitive than the layer-2 information used for anti-spoofing.