Subject: [SAVA] SAVI Charter Revision after Vancouver

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Tue, 08 Jan 2008 15:11:24 +0200

Mark -

> Hmm. I think transit packets are out-of-scope for SAVI.

That's right.  I suggest rephrasing bullet 2 in the current charter 
proposal from...

- The solutions verify the addresses of hosts; verification of router
   addresses is out of scope

...to...

- The solutions verify the IP source addresses in packets on the first
   hop; IP source address validation for packets forwarded by a router is
   out of scope

Note that this change will allow a SAVI solution to validate the IP
source addresses in packets sent by a router -- although this validation
will be limited to the packets' first hop.

> Tend to agree here. It's the way it might end up, but at this stage I 
> don't like to exclude any address-provisioning method.

The current charter proposal does not exclude any address provisioning
method as far as I see.

- Christian

---

From: fred at cisco.com (Fred Baker)
Date: Tue, 8 Jan 2008 12:33:35 -0800

On Jan 8, 2008, at 5:11 AM, Christian Vogt wrote:

> source addresses in packets sent by a router -- although this  
> validation will be limited to the packets' first hop.

It presumes that we can distinguish between datagrams sent by the  
layers above IP in a router from those that IP forwarded. Let me draw  
you a picture:

                +----------------+
                |                |
                |+-------+------+|
                || SNMP  |Trojan||
                ||Process|Module||
                |+-------+------+|
                |+--------------+|
                ||   IP Protocol||
                |+-+--------+---+|
                +--+--------+----+
                   |        |
           ---+----+---   --+-----+-------
              |                   |
           +--+---+            +--+-+
           |Remote|            |SAVI|
           | Host |            |Host|
           +------+            +----+

Here we have three hypothetical systems - a router with at least two  
interfaces and a host on either side. The "SAVI Host" receives four  
separate datagrams, each containing the MAC address of the router  
interface on its side and one of four IP addresses:

  - a datrgam correctly initiated by the remote host and forwarded by  
the router
  - an SNMP response correctly originated from the router's "remote"  
interface
  - an SNMP response correctly originated from the router's "local"  
interface
  - some other message originated with a spoofed address by the  
Trojan in the router

By what set of rules does one disambiguate this?

SeND gives us a way for the SAVI Host and its Router to manage  
address exchanges for the local LAN. The set of requirements I  
described similarly enable the host to be sure of the routers local  
LAN address when standard ND is used, but with a lower level of  
assurance. Since neither ND nor SeND are negotiated for remote  
addresses, they don't help with the Trojan, the remote host, or the  
non-local address on the router. Standard uRPF or filter-based  
ingress filtering can be used to provide a reasonableness check on  
the other addresses, but this is what Wu's problem statement asserts  
is inadequate - if the Trojan guessed a prefix that happens to match  
the uRPF criteria, it will not be detected.

I don't see how one distinguishes between a datagram originated by a  
router and one forwarded by a router. If you say that the TTL on a  
datagram originated by a router must be 255, then having the Trojan  
set its TTL to 254 means that the test isn't applied to its traffic.

I think datagrams that go through a router, whether forwarded or  
originated there, have to be ruled out of scope, unless someone can  
give me a set of rules to address this.

I also think that this isn't properly a charter question, it is a  
technology question. If the working group is smarter than I and comes  
up with a way, the charter shouldn't say that we're not allowed to  
propose it. I think that the charter should simply say that we are  
working on the local LAN variation on ingress filtering, and that  
further discussion of routing-based ingress filtering is either out  
of scope or is a second topic.

---

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Wed, 09 Jan 2008 12:56:29 +0200

Fred -

if we knew that hosts on the same link never exchange packets via a
router, then a receiving host could judge from the IP source address
prefix of a packet received from a router whether the packet was
originated or forwarded by the router:

- If the prefix is on-link, the receiving host would initiate an NS/NA
   exchange to verify the packet's IP source address.
- If the prefix is off-link, no IP address validation would occur.

The special case where the host receives a packet from the router's
remote interface would then be considered a forwarding event.

However, these IP source address validation rules yield a false negative
when hosts on the same link exchange packets via a router:  The router
would in this case be the packet sender, and the NS/NA exchange would
falsely indicate that the packet's IP source address is false.

It therefore indeed seems that IP source address validation should be
omitted for packets received from a router -- be it packets that were
forwarded or originated by the router.  A host could check its
default-router list [RFC 4861] to decide whether an on-link packet
sender is a router or a host.

- Christian

---

From: fred at cisco.com (Fred Baker)
Date: Mon, 14 Jan 2008 11:34:41 -0800

Sorry, for whatever reason I am just seeing this note.

Yes. What I would suggest is that any system (switch or host/router)  
have an exception list that identifies systems, ports, etc that it  
should not attempt to verify. The default-router list would be an  
obvious set of systems that a host should not attempt to verify. On a  
switch, if it is tying IP addresses to ports, it should be able to  
exclude trunk ports (ports to other switches), as there is  
potentially an arbitrarily large number of addresses to associate  
with them.

---

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Tue, 15 Jan 2008 01:24:05 +0200

> exclude trunk ports (ports to other switches), as there is potentially 
> an arbitrarily large number of addresses to associate with them.

Yep, this makes sense.

- Christian