Subject: [SAVA] Charter Proposal To Be Discussed at BoF

From: fergdawg at netzero.net (Paul Ferguson)
Date: Wed, 5 Dec 2007 15:33:47 GMT

- -- Jari Arkko <jari.arkko at piuha.net> wrote:

>> I mean, having a solution tied to DHCP is important, but actually there
>> needs to be solutions for all methods of IP address provisioning.
>
>Its late so I'm probably missing something. But which methods are you
>talking about?
>

Hi Jari,

It's early, and I haven't even had my first cup of coffee yet, but
I'll take a stab at this.

First, it would appear to me that by binding SAVI to DHCP (for
IPv4), that would (seem to imply, at least to me) that we're talking
about host-based source validation -- which cannot be trusted.

My impression that the most critical place to do validation is
at the (IP) first-hop -- and I'm unclear here where & how DHCP plays
into this.

A RFC2827/BCP38 -style validation could easily be done there, based
on either loose (prefix) or strict (MAC) enforcement.

At least that is how I always envisioned SAVI/SAVA being done for
first-hop.

Perhaps I missed a document revision somewhere, or missed as
consensus somehow, so perhaps if someone could explain to me how
DHCP comes into this equation (or point me to specific document
paragraph), I'd be happy to acquiesce. 

Also, I'm a little concerned about statically addressed hosts on
a segment (which in a data center or hosting provider will be a
very high percentage) because of ARP spoofing issues.

Thanks,

- - ferg

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/
_____________________________________________________________
Click to make millions by owning your own franchise.
http://thirdpartyoffers.netzero.net/TGL2221/fc/Ioyw6i4t12iipMvzfVDd88l1eAWtEuza4xFeW6dtXR5xFNhwNwXSyx/

---

From: fred at cisco.com (Fred Baker)
Date: Wed, 5 Dec 2007 07:59:24 -0800

> about host-based source validation -- which cannot be trusted.

Cisco and Foundry's IP Source Guard features depend on DHCP snooping  
in the switch.

> at the (IP) first-hop -- and I'm unclear here where & how DHCP plays

it tells you what to validate against. You know what the host is  
authorized to use.

> very high percentage) because of ARP spoofing issues.

If someone is willing to manually configure a host, it is not  
unlikely that they can manually configure the filter as well. The  
question is "how do you know what the host SHOULD say and discard  
datagrams that say something else"