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

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

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

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

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.

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

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.

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

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.

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

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

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

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. 
> 6man doesn't like it.

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

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

Yes, that was a tautology.

- Christian