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

[Stephen Farrell <[e-mail]>]

Richard, Jean-Michel,

I think this is an interesting discussion, (though perhaps as WG
chair, Jean-Michel has done parts of it before:-) but in any
case I think the meat of Richard's comments are covered in the
various IESG discusses and comments [1] from the May 26 telechat
agenda which included this document.

So, by all means continue discussion, but I don't want you to
waste cycles unnecessarily. Richard - if there're aspects of your
review that are not captured in the IESG discusses and comments
then maybe just highlight them and we can pursue those points
separately as appropriate.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope/ballot/

On 14/06/11 23:41, Jean-Michel Combes wrote:
> Hi Richard,
> 
> 2011/6/14 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,
> 
> Yes.
> 
>> but it never states clearly at which points the SAVI mechanism is intended to be applied.
> 
> I agree. Now, this is not the goal of this document but the SAVI
> Framework one (cf. Section 1 of Framework document).
> To come back to your comment, section 6 introduces the fact that
> performing anti-spoofing protection at the host level is better than
> the existing mechanism previously described.
> 
>>  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.
>>
> 
> Maybe I am wrong, but here you are assuming you assign a network
> prefix per host to still use existing mechanisms like BCP 38/uRPF,
> correct?
> 
>> Thus, the document should clearly state that SAVI is limited to spoofing within a local layer-2 network, before it reaches a router.
> 
> Sorry, but I don't understand: what do you mean by "SAVI is limited to
> spoofing within a local layer-2 network"?
> By the way, a SAVI device could be a router even if common use case is a switch.
> 
>> 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.
>>
> 
> In fact, this is a goal and not a result/consequence of the SAVI
> solutions: present anti-spoofing solutions have not the correct
> granularity to stop IP spoofing based attacks.
> 
>> 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).
>>
> 
> Propagation? This document doesn't describe any protocol allowing such a thing.
> Now, if I want to know the MAC-IP binding, IMHO, on a LAN scope, in
> most of the case, tcpdump/ethereal/wireshark should be enough :)
> More seriously, I understand your concern: not to propagate such type
> of information. But, today, security tools (e.g. NAT - ok, this is not
> a security tool :), firewall, IPsec gateway, etc.) are logging
> information and nothing could prevent propagation of such information
> ... Do we stop to log information to track attackers?
> 
>> Another ambiguity that raises privacy concerns is the document's discussion of binding anchors. The document uses the phrase "binding anchor" without definition.
> 
> Correct. Maybe, a solution would be to remove the sentence from here
> and to add a reference to 802.11i (cf. bellow) in section 3.2 of the
> Framework document (i.e. in the sentence "The security association
> between a host and the base station on wireless links.")
> 
>> 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.
>>
> 
> IMHO, there is a typo: s/802.1x/802.11i
> 
>>
>> 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.
>>
> 
> AFAIK, described attacks are not limited to network-internal resources.
> One of the goals of this document was to describe in a single document
> all known IP spoofing based attacks (the other goal was to describe
> the limitations of the today IP anti-spoofing protection mechanisms).
> 
>> 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.
> 
> No, no, no, no!!! :)
> 
> I don't know if IETF works exist for IPv4, but for IPv6, the solution
> you are describing is more or less Secure Neighbor Discovery (SEND
> [RFC3971]), even if SEND doesn't provide an assurance about the MAC
> address ownership.
> The goal of the savi WG is to forbid the use of a spoofed IP address
> as source address in an IP packet outside the SAVI perimeter (cf.
> Framework document for more details about SAVI perimeter).
> 
>>  By basing the solution at end hosts
> 
> No, no, no, no again!!! :)
> 
> The solutions are only based on signaling exchanged between hosts
> (e.g. NDP/SEND) or host/server (e.g. DHCP) with an exception with DHCP
> SAVI mechanism which uses RFC 4388 and RFC 5007 too.
> 
>> , 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.
>>
> 
> Again, IMHO, you miss the fact that SAVI goal is to avoid spoofed IP
> based outside the link/LAN.
> 
>>
>> 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.
>>
> 
> Please, see my reply to Stephen about this:
> 
> http://www.ietf.org/mail-archive/web/savi/current/msg01635.html
> 
>> Anti-spoofing mechanisms are a limited subset of traceability mechanisms.
> 
> Because of the granularity level ... and so such mechanisms are less efficient.
> 
>>  They support attack mitigation/forensics by ensuring that the view of the network from DHCP lease tables and ND caches is correct.
> 
> AFAIK, SAVI solutions only use such of information. Don't hesitate to
> read SAVI solutions, I will appreciate :)
> 
>>  More general traceability mechanisms can involve binding addresses to other data like network access credentials and user identifiers.
> 
> Again, AFAIK, SAVI solutions are based on neither access credentials
> nor user identifiers (I said "user" and not node ID).
> 
>> These data are not required for anti-spoofing, and are clearly much more privacy-sensitive than the layer-2 information used for anti-spoofing.
>>
> 
> cf. my previous comment.
> 
> Thanks in advance for your reply.
> 
> Best regards.
> 
> JMC, savi WG co-chair.