Subject: [SAVA] proposed charter

From: jari.arkko at piuha.net (Jari Arkko)
Date: Tue, 29 Apr 2008 22:53:58 +0300

All,

Here's a proposed charter for the SAVI WG. It has been sent for IESG and
IAB review. If and when this is successful, there will be public IETF
review. If people on this list have comments on the charter, please let
me know by next week's Wednesday.

We've been waiting with SAVI in order to address two issues: (1)
documentation of threats and how SAVI would improve things over what we
can already do with BCP 38 & friends, and (2) dealing with a bigger set
of situations (multiple MAC addresses, multiple addresses, mobility,
multihoming, ...) than the vendor solutions.

For the first issue, the beginning of the new charter tries to explain
that SAVI is really just about making BCP 38-like filtering possible in
more circumstances than it now is. For instance, if you interface to my
customer is a PPP link, I can do it today. But if all my customers are
attached my Ethernet switch, I have a much harder time doing ingress
filtering. Secondly, Danny has written a new draft
(http://tools.ietf.org/html/draft-mcpherson-savi-threat-scope). While
clearly a -00, I think it says what we need to say about issue 1 at this
stage. In particular, as long as we are not doing the IPv4 checking on a
32 bit boundary and on all kinds of link types, we can see some
potential improvements.

The other issue is harder. Christian and I did some work together to try
to understand what can and cannot be done in this space. We've also had
a discussion about this with a few interested parties. There are many
interesting ideas on what we could do, and almost everything that we
want to handle can be handled. Certainly much more than some of the
existing designs. However, we suspect there are fundamental limits --
anycast address usage, for instance, would look very similar to a
spoofing attack. As a result, the best that we may be able to do in such
situations is to log suspected spoofing attempts. Or require explicit
configuration to enable blocking of spoofed packets in environments
where this is possible. My belief is that this is sufficient to make an
improvement in the Internet -- and I believe there is market demand for
this. The charter takes the approach that it lists the situations we
want to be able to handle, explains which of them are likely hard, and
lets the actual design & tradeoffs be done by the WG.

Thoughts, comments, suggestions?

----

Source Address Validation Improvements (SAVI)

While ingress filtering [RFC 2827, BCP 38] provides a way to validate
IP source addresses at an aggregated level, there is not yet a
standardized mechanism for IP source address validation at a finer
granularity. Having a finer granularity would be helpful in a number
of situations, including filtering traffic from customer interfaces
implemented as ports in a switch, general improvements in filtering
accuracy in enterprise networks, etc. Depending on the situation,
there may be a requirement for blocking spoofed packets or merely
logging packets that appear to be spoofed.

Partial solutions exist to prevent nodes from spoofing the IP source 
address of another node in the same IP link (e.g., the "IP source 
guard"), but are proprietary.  The purpose of the proposed "Source 
Address Validation Improvements" working group is to standardize 
mechanisms that prevent nodes attached to the same IP link from 
spoofing each other's IP addresses. 

The scope of the WG is as follows:

- The working group considers only solutions implemented on systems
  located on the same IP link as a to-be-verified node. The goal of
  the working group is the LAN environment and solutions running in
  an Ethernet switch.

- Both IPv4 and IPv6 need to be covered.

- All address assignment mechanisms need to be supported, including
  stateless, stateful, and manual configuration; as well as privacy and
  cryptographically generated addresses.

- Solutions are based on observing existing protocols and not
  introducing new protocols. Examples of protocols that can be
  useful are ARP, Neighbor Discovery, DHCP, and DHCP Prefix 
  Delegation protocols. Observing addresses in IP headers
  of other protocols can also be useful.

  The gathered information is used to determine what
  source addresses in packets are appropriate.

- Tracking other protocols, such as routing protocols,
  is not within the scope of the WG.

- No changes to hosts are allowed. 

- The WG is prohibited from creating its own protocols 
  or extensions of current protocols.

These limitations in the scope may be relaxed through later 
rechartering. For instance, solutions tailored for PPP links 
and specific environments such as DSL may be added later, or 
solutions involving co-operation of the nodes on the link may
be developed once the baseline solutions have been completed.

In order to reach a result that is widely usable and unlikely to
disturb existing network practices, the working group needs to
take into account

- nodes that use static addresses,
- nodes with multiple IP addresses on the same interface,
- nodes that use multiple link-layer addresses on the same interface,
- attachment of another switch at a switch port,
- presence of routers, NATs, and other similar devices on the same link,
- use of SEcure Neighbor Discovery in some networks,
- nodes that have multiple interfaces to the same link,
- nodes that move to another port on the same link, and
- hosts with anycast addresses.

However, should such wide applicability turn out to be impossible, 
the working group will document the limitations of the solutions 
in due manner. In particular, it is likely that anycast addressing
and nodes that employ multiple interfaces for load balancing at 
link layer are indistinguishable from an actual spoofing attack. 
There may also be a difference in the applicability between blocking
and merely logging spoofed packets. In any case, the solutions 
may require to be explicitly turned on for each network or interface
where they are applicable.

For background information, the working group will also develop a 
threats analysis document that describes what threats the solutions 
from the WG protect against. This document also contrasts SAVI
to existing solutions. 

Milestones:

Jun 08    WG approval
Jul 08    First WG draft on threats document
Oct 08    First WG draft on IPv4 solution
Oct 08    First WG draft on IPv6 solution
Oct 08    Submit document on threats to IESG for Informational RFC
Mar 09    Submit IPv4 solution to IESG for Proposed Standard
May 09    Submit IPv6 solution to IESG for Proposed Standard