Subject: [savi] Another review of SAVI Threat Scope document

From: Christian Vogt <[email-masked]>
Date: Sun, 12 Oct 2008 03:48:54 +0300

Fred, Danny,

you did a great job with the SAVI Threat Scope document
[draft-mcpherson-savi-threat-scope], I think.  The document has a great
overview of threats, and also talks in quite a bit of detail about what
solutions already exist.  Of course, the document is still a 00 version,
and will have to undergo some revision.  Marcelo already made several
good comments, and I, too, have a suggestion for improvement:

Since one of the roles of the Threats document is to serve as a problem
statement and motivation for SAVI, I would suggest elaborating a bit
more on is the part that talks about shortfalls of existing solutions
and, in particular, where and how the prospective SAVI solution would be
of value.  I am attaching text that you may copy into the document as a
new section.

- Christian

Existing Techniques for IP Source Address Validation
----------------------------------------------------

Existing techniques for IP source address validation are insufficient
for at least one of the following reasons:

- False negatives.  Techniques may yield false negatives, thus
   enabling an attacker to select an IP source address that is
   spoofed, but still passes IP source address validation.

- False positives.  Techniques may yield false positives, thereby
   causing interruption or denial of service to hosts that use
   legitimate IP source addresses.

- Non-trivial configuration.  Requirements for non-trivial
   configuration imply expenditures and pose a risk for
   misconfiguration, which may again lead to false positives or false
   negatives.  Both may discourage operators from using a technique.

- Proprietary.  Procurement policies oftentimes require techniques
   that are standardized, hence hindering or preventing the
   deployment of proprietary techniques.

The only standardized technique for IP source address validation is
ingress filtering [1].  This calls for routers to check whether
the prefix of a to-be-forwarded packet's IP source address is amongst
a list of prefixes considered legitimate for the interface through
which the packet arrives.  Packets that fail this check are discarded.

Ingress filtering may yield false negatives in deterministic manner.
Packets with a legitimate IP source address prefix, but a spoofed
interface identifier, pass ingress filtering checks.  Also, packets
with an illegitimate IP source address prefix pass the checks as long
as the prefix is from the list of prefixes considered legitimate.

Ingress filtering implementations that require manual establishment of
the list of legitimate prefixes cause considerable configuration
overhead.  Unicast Reverse Path Forwarding [2] mitigates this issue by
automatically deriving the list of legitimate prefixes from a router's
forwarding table:  A to-be-forwarded packet's IP source address prefix
is considered legitimate if the packet is coming through an interface
via which return traffic would be routed.  On the other hand, Unicast
Reverse Path Forwarding may yield false positives, in particular for
hosts and networks with multiple, topologically separate Internet
attachments [3].

Consequently, there is a need for an IP source address validation
technique that avoids false negatives and false positives, that can be
set up with no or only trivial configuration, and that has been
standardized.  The development of such a technique is the goal of the
proposed Source Address Validation Improvements working group in the
Internet Engineering Task Force.

[1]  Paul Ferguson and Daniel Senie.  Network Ingress Filtering:
      Defeating Denial of Service Attacks which employ IP Source Address
      Spoofing. IETF Request for Comments 2827, Best Current Practice
      38, May 2000.

[2]  Cisco Systems.  Unicast Reverse Path Forwarding. Cisco IOS
      Documentation, May 1999.

[3]  F. Baker and P. Savola.  Ingress Filtering for Multihomed
      Networks. IETF Request for Comments 3704, March 2004.

---

From: Danny McPherson <[email-masked]>
Date: Mon, 10 Nov 2008 22:28:19 -0700

On Oct 11, 2008, at 6:48 PM, Christian Vogt wrote:
> interface identifier, pass ingress filtering checks.

Can you tell me what you mean by the above, WRT spoofed
interface identifier?

-danny

---

From: Christian Vogt <[email-masked]>
Date: Tue, 11 Nov 2008 09:46:55 +0200

> Can you tell me what you mean by the above, WRT spoofed

Hi Danny,

my above statement is referring to the limitation of ingress filtering
that only a prefix is validated, i.e., at most the 64 most significant
bits.  The 64 least significant bits are what I call the "interface
identifier".  These don't get validated by ingress filtering.  If you
spoof the interface identifier, but not the prefix of an IP address,
ingress filtering will pass the IP address, yielding a false negative.

- Christian