[SAVA] Review of draft-baker-sava-cisco-ip-source-guard-00

[christian.vogt at nomadiclab.com (Christian Vogt)]

Fred,

thanks for documenting Cisco's IPv4 Source Guard protocol.  This will be
a very useful reference for the work ahead in SAVI.  Couple of comments:


Section 2, 3rd paragraph:

    As described, the feature is clearly one implemented on an IP or
    Ethernet switch intended for use in a SOHO, corporate, or access
    network.  It is not, at this writing, supported on Cisco routers, nor
    is it something one would expect to be implemented on a host.

I think the last part of the latter sentence can be dropped because an
implementation on a host would theoretically be feasible.  Why not have
a host implement the Source Guard and have it verify the source address
in packets received directly from a neighbor?

    Interoperability is not a requirement per se; if the DHCP client and
    server are interoperable with each other, spoofing is adequately
    eliminated.

Better just state that there are no interoperability issues because the
Source Guard works with standard DHCP and no extensions are necessary.


Section 2.1, 1st paragraph:

    In the IPv4 architecture, it is legal to have more than one IP
    address on a host, and there are systems (including routers and some
    hosts) that routinely send datagrams using a source IP address that
    differs from the interface's primary IP address.  However, in the
    general case, a host has one address for each interface, and in the
    general case, a host has one interface.  It is this case that the IP
    Source Guard feature addresses.  By dropping all IPv4 datagrams from
    such hosts that use a different address than the one assigned, the
    feature severely limits a network's ability to introduce spoofed
    source addresses to the Internet.

Why would hosts with multiple interfaces be a problem?  Since the
Source Guard sees only interfaces, it does not care if multiple
interfaces belong to the same host.

Additionally, why would hosts with multiple IP addresses per interface
be problematic?  One simply needs to bind a single link layer address to
multiple IP addresses.

Similar case with NATs, which are listed as a pitfall in the 3rd
paragraph of section 2.2:  They should work with the Source Guard if you
set up multiple IP/link-layer address bindings for the same link-layer
address.


Section 2.1, 2nd paragraph:

    One could argue that this done not help the local network, but one
    would be wrong.  An attack that happens elsewhere in the Internet can
    and does happen on the local LAN and in the IP network that a host
    resides in.  Hence, while the degree may not be the same, eliminating
    address spoofing remains the first step in removing several classes
    of attacks from one's network, and is therefore a good idea.

This paragraph is a bit confusing.  I think we should identify two goals
here:

- Security benefits local to the network deploying the Source Guard,
   such as detection of infected hosts, reliability for administration
   and accounting, secure firewall/NAT bindings, etc.

- If/when widely deployed, increased reliability of IP source addresses
   globally, not just locally within a network.


Section 2.2, 1st paragraph:

    IP Source Guard assumes that some ports on a switch - those whose
    single interface has one address - are "protected" and others are
    not.  "Others" include systems with multiple interfaces, which might
    as a result receive a datagram through one interface and respond to
    it ("from" the IP of that interface) on the other, for which this
    capability is obviously problematic.  "Others" also includes routers,
    prefix-based NATs, and others, which may originate traffic from a
    variety of addresses that are not within the local prefix.

IMO, a host that sends packets through one of its interfaces with a
source address configured on another of its interfaces does misbehave.
Hence it is OK to filter such packets.  After all, the packets would
also get filtered if the two interfaces happened to connect to different
links, and ingress filtering was applied on access routers.


Section 2.2, 2nd paragraph:

    The problem on a router interface should be obvious: a router
    forwards datagrams sent by other systems, which carry the source
    address of their originators.  If this feature is applied to a router
    interface, the data it is forwarding will be discarded, nullifying
    its usefulness without advising either the network or its users of
    the fact - a clear violation of the End-to-End principle.

Simply state that the Source Guard can verify the IP addresses of only
non-forwarding hosts.  As I said above for section 2.1, 1st paragraph,
that sould work also for hosts with multiple IP addresses on an
interface and for NATs.


Section 2.2, 3rd paragraph:

    The problem on other varieties of devices - NATs that use multiple
    addresses, hosts that have "primary" and "secondary" addresses, and
    hosts with multiple LAN interfaces - is of the same nature.  The
    system will be prevented from carrying out an intended function when
    using an address other than the one that the switch is enforcing the
    use of.

See my comments above for section 2.1, 1st paragraph.

Best,
- Christian