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

[fred at cisco.com (Fred Baker)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 23, 2007, at 11:05 AM, Christian Vogt wrote:
> 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?

If you're asking about Cisco's implementation, which is specifically  
what was requested and what I documented, Cisco doesn't make hosts.

>    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.

it does care about addresses uses by the host. If the host has  
multiple interfaces, it has multiple addresses, and there are cases  
where a host will use the address from one interface on a message  
transmitted on another (for example, if it is replying to q request  
and its route table specifies an interface to send the datagram on).  
If it is limiting the use of the interface to a single address, that  
will scotch such a message.

> 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.

While that happens in IPv4, it is not common (it is fairly ancient  
BSD technology and no longer widely used), and the Cisco  
implementation very specifically limits the host to a single address  
on the interface, the one assigned using DHCP.

> 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.

They will if it is the type of NAT that overlays all traffic on one  
address. Not all NATs do that.

> 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.

you're welcome to your opinion. The question is whether the message  
is a request or a response. Yes, a request sent on an interface  
should use that interface's address. A response must use he address  
to which its request was sent, else the peer will not be able to  
correlate it with its request. But the route table in the host can  
send it out any interface. It's a bug, yes, but it is the truth.

See draft-baker-6man-multiprefix-default-route for a way around that.  
6man doesn't like it.

> 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.

You seem to have missed RFC 2460's definition of a router and a host.  
A system that forwards a datagram is a router; any other system is a  
host. There *are* no 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.

See my comments on same.

> 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.

See my comments on same.

-----BEGIN PGP SIGNATURE-----

iD8DBQFHSk/XbjEdbHIsm0MRAnbXAKDAW82miXUKi+hJGzczOkN/Ln/9bwCgqx7z
f0feGsFMoh78ai58aIQcRLQ=
=+z3a
-----END PGP SIGNATURE-----