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

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Fri, 23 Nov 2007 21:05:44 +0200

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

---

From: fred at cisco.com (Fred Baker)
Date: Sun, 25 Nov 2007 20:47:19 -0800

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

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

> be problematic?  One simply needs to bind a single link layer  

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.

> set up multiple IP/link-layer address bindings for the same link-layer

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

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

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

See my comments on same.

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

See my comments on same.

---

From: fred at cisco.com (Fred Baker)
Date: Sun, 25 Nov 2007 21:02:31 -0800

On Nov 25, 2007, at 8:47 PM, Fred Baker wrote:

> There *are* no non-forwarding hosts.

arg.

correction: all hosts are non-forwarding.

---

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Mon, 26 Nov 2007 17:25:04 +0200

Fred -

Most of my comments were because I am looking at the Source Guard idea
conceptually, while you were describing Cisco's implementation in
particular.  It would be good to stricter distinguish between the two in
the draft.  This will make it clear that features not supported by the
current implementation do not necessarily conflict with the Source Guard
idea as such -- like the use of multiple IP addresses per interface.

More comments below...

> what was requested and what I documented, Cisco doesn't make hosts.

Sure, just change the wording a bit.  Currently the draft says that one
would not "expect" the Source Guard functionality to be implemented in
hosts.  What it should say is that there is no host implementation for
it, but that it would in principle be feasible.

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

My thinking was that it would be OK to filter packets with a source
address from a different interface than the transmitting one.  The
reason is that such a source address would be incorrect anyway.

So the question is if a source address validation technique should allow
hosts to use any of their IP addresses as a source address for sending
via any of its interfaces.  Personally, I don't fully agree that the
fact that this is a "prevalent bug" means that source address validation
techniques should permit it.  Permitting it would make the techniques
either more complex, or inapplicable to scenarios with multi-interface
hosts.

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

That's fair enough.  I wonder, though, if you could differentiate a bit
clearer between the Source Guard idea as such and Cisco's implementation
specifically.  I think the Source Guard idea is conceptually well
compatible with hosts which have multiple IP addresses per interface,
even though the currently available implementation might be more
restrictive.

> address. Not all NATs do that.

I don't see a problem even if the NAT would use multiple external
addresses.  All of those addresses would have to be bound to the NAT's
single link layer address; that should do it.

But maybe we are talking about two different things here...

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

I do see your point, Fred.  And it is likely that we won't be able to do
anything about it because we don't have a host identify available to
which IP addresses could be bound -- we only have interface IDs.

The best is probably to explicitly state that the described host
behavior is incorrect, but that it is a common phenomenon due to which
the Source Guard feature may have to be disabled.

> See draft-baker-6man-multiprefix-default-route for a way around that. 

Section 2.2 of draft-baker-6man-multiprefix-default-route would already
be enough.

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

Yes, that was a tautology.

- Christian