Subject: [savi] Minutes/summary of SAVI session at IETF?

From: Derrick Kong <[email-masked]>
Date: Tue, 12 Aug 2008 13:13:47 -0400

Hello,

Does anyone have a summary/minutes of the SAVI session at IETF?   
There doesn't seem to be an audio archive of session available sadly.

Derrick Kong
[email-masked]

---

From: "Stephen Hanna" <[email-masked]>
Date: Wed, 13 Aug 2008 14:47:53 -0400

> There doesn't seem to be an audio archive of session available sadly.

Yes, I was disappointed to find SAVI missing from the audio archive.
Here's a WG summary that I wrote up this week.

Thanks,

Steve

-----------

SAVI WG Report, IETF 72

Christian Vogt and Bill Fenner co-chaired the first meeting of the
SAVI WG. Slides and agenda for this meeting are available from
https://datatracker.ietf.org/meeting/72/materials.html Minutes
should be available from there soon. The audio recording did not
seem to work. Here is a brief summary of the meeting.

Christian started by summarizing the charter and goals of the
SAVI WG. IP source address spoofing is used for various unpleasant
purposes: DDOS, circumventing access controls, etc. Source address
validation can eliminate or reduce these problems.

Three source address validation technologies exist but are not
ideal. Ingress filtering and unicast Reverse Path Forwarding (RPF)
are very coarse. Cisco's IPv4 Source Guard is not standardized.

SAVI aims to provide source address validation on a single link
(i.e. before the first-hop router). Broader scopes can be addressed
with different technologies. The SAVI charter dictates certain
requirements and constraints. For instance, SAVI cannot require
host changes and must work by observing existing protocols.

Christian then presented a framework and taxonomy of SAVI solutions.
The framework is that a SAVI solution maintains a database of bindings.
A binding is a linkage between a source IP address and a binding anchor
(a switch port or lower-layer address). The lifecycle of a binding is:

1) SAVI solution establishes binding
2) SAVI solution verifies binding
3) SAVI solution enforces binding (if conflicts detected)

The taxonomy has the following axes:

Which binding anchor?
A) Switch port
B) Link layer address

How are bindings verified?
A) Check sending host (direct)
B) Ask other hosts (indirect)

How are binding conflicts handled?
A) Drop packets that clash with binding
B) Reverify binding

Christian's slides lay out a list of challenges (e.g. host
mobility across switch ports with the same source IP address)
and analyzes whether the various options handle these challenges.

Questions were raised about whether this framework and taxonomy
span all the possible solutions to this problem.

Fred Baker described the solutions laid out in his draft,
draft-baker-sava-implementation-00.txt. These mainly involve snooping
DHCP for IPv4 and Neighbor Discovery for IPv6. Erik Nordmark pointed
out that an attacker who spoofs MAC and IP on a non-switched LAN
can't be detected. Fred agreed.

Gang Ren described the solution laid out in his draft,
draft-wu-sava-solution-firsthop-eap-01.txt. He suggests having
the RADIUS server send the IP address in the Access-Accept.
He admitted this only works for 802.1X but still thinks it's good.
Others asked why change protocols? The same thing can be accomplished
with DHCP snooping at the switch.

Jun Bi described the solution laid out in his draft,
draft-sava-solution-ipv6-firsthop-authentication-00.txt. Hosts
sign packets using AH or a new option header. If Cryptographically
Generated Addresses (CGA) are used (with IPv6), this can establish
the host's right to use the address. Concerns were raised that
this requires changes to the hosts and protocols.

Erik Nordmark gave a presentation. He admitted that there are
lots of tricky issues and situations here. We must make a
tradeoff between complexity and features. Erik suggested a
simple system (described in his slides) where switches would
watch which port uses a source IP address. Whoever uses it first
gets to keep it as long as they respond to pings. See his slides
for more details. Someone pointed out that many endpoints don't
respond to pings these days. Erik said use ARP. Someone else
said this doesn't span switches. Erik said that could be added.
Someone pointed out this isn't very secure. True, said Erik.
We could make it more secure but then it will be more complex.

Steve Hanna mentioned that IF-MAP (to be discussed during SAAG)
will provide a central database that can be used to manage source
IP address assignments and relate those to ports, MAC addresses,
and user identity.

In the discussion at the end, questions were raised about
the purpose of the group. Should we protect against spoofing
by off-link parties? Some thought yes, some no.

---

From: Christian Vogt <[email-masked]>
Date: Fri, 15 Aug 2008 12:57:44 -0700

> Here's a WG summary that I wrote up this week.

Attached are further meeting minutes by Jun Bi.

Thank you, Stephen and Jun, for your help!

- Christian