BOF Description:

First, we need everyone to wipe their minds about the earlier SAVA
proposals. What we have now on the table is completely different, and
very focused.

For background, the SAVA effort started a year ago from a very
ambitious plan that involved improvements in being able to validate
decisions made networks on the other side of the planet. For various
reasons the IETF community has not found this approach worthwhile to
pursue. The primary reason in my mind is that the required changes in
the routers and supporting infrastructure would be extremely costly
for what appears to be an improvement of debatable value. However,
this does not necessarily imply that there is no work in this
space. Indeed, when talking about the topic we found vendors and users
doing simple things to provide better support against address spoofing
in their local networks.

With this in mind, we met in Helsinki a couple of weeks ago to do a
reset and see if there was something concrete that we could do. My
conclusion from those discussions was that there's plenty of research
topics in this space that should stay as such. But at the same time,
there were also concrete items relating to checking for address
spoofing in a local network that would seem to benefit from
standardization.

One of these items was what Cisco and other vendors do for IPv4
address spoofing checks in a switch; the question is whether an IETF
specification of such behavior would be useful. We think so, because
an IETF document of an existing practice can make it more attractive
to a wider range of users and vendors. Another item was the same
feature in IPv6. This is currently not implemented, and is technically
more challenging than the IPv4 version. However, it appeared to be a
feasible task for IETF work. And we believe doing this would be
useful, because if left to individual programmers, we probably have
many different versions of it, some not completely functional in all
circumstances.

This is a link layer dependent effort, focused only on Ethernet at
this time. But making IP run over link layers is within IETF's scope,
and I believe we are better equipped than the link layer organizations
to think about what IP layer messages need to be tracked to achieve
the desired functionality.

We believe these two tasks would justify a focused WG. However, one of
the gating items is whether the proponents of the WG are capable of
delivering an early draft of the IPv6 specification. As of today, we
still do not have this draft. IPv4 draft does exist.


Charter proposal below:


Source Address Validation Improvements (SAVI)

Co-chairs
TBD

Internet Area Directors:
Jari Arkko <jari.arkko@piuha.net>
Mark Townsley <townsley@cisco.com>

Internet Area Advisor:
Jari Arkko <jari.arkko@piuha.net>

Mailing Lists:
General Discussion: sava@nrc.tsinghua.edu.cn
To Subscribe: http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava
Mailing List Archive: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/
Document Repository: http://narl.tsinghua.edu.cn/sava

While the MIT Spoofer project has measured that about 75% of networks
deploy ingress filtering, ingress filtering at a finer granularity is
not yet as common.  A number of proprietary mechanisms exist (e.g.,
"IP source guard") which offer partial solutions to prevent hosts from
spoofing the source address of another host in the same subnet.  The
purpose of the proposed "Source Address Validation Improvements"
working group is to standardize mechanisms to prevent source address
spoofing in the access network.

Specifically, the group shall define solutions such that hosts
attached to the same router cannot spoof each other's addresses. The
following assumptions apply:

- The WG considers only solutions on layer 3 aware Ethernet switches.

- Two solutions are needed, one for IPv4 and another one for IPv6

- The IPv4 solution depends on tracking the DHCP traffic on a port.

- The IPv6 solution depends on tracking the ND and DHCP traffic on a port.

- All address assignment mechanisms in IPv6 need to be supported,
  including stateless, stateful, privacy, and so on.

- The solutions are turned on for on host ports by configuration, and
  do not apply to routers.

The WG recognizes anti-spoofing deployment efforts, motivation, and
best practices development in various forums around the world
(including RIPE). The WG is only chartered to deliver two specific
solution components that such efforts could employ. The bigger
questions are out of scope.

Milestones:

Done      First draft on IPv4 solution
Oct 07    First draft on IPv6 solution
Oct 07    BOF decision
Dec 07   BOF in IETF-70
Jan 08    WG approval
Feb 08    First WG draft on IPv4 solution
Apr 08    First WG draft on IPv6 solution
Jun 08    Submit IPv4 solution to IESG for Proposed Standard
Dec 08   Submit IPv6 solution to IESG for Proposed Standard