Subject: [SAVA] Thinking simpler...

From: fred at cisco.com (Fred Baker)
Date: Mon Mar 19 23:39:28 2007

Any comments?

     ftp://ftpeng.cisco.com/fred/sava/Sava-Simple.txt
     ftp://ftpeng.cisco.com/fred/sava/Sava-Simple.xml

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Tue Mar 20 04:23:41 2007

On Mon, 19 Mar 2007, Fred Baker wrote:
> Any comments?
>
>    ftp: //ftpeng.cisco.com/fred/sava/Sava-Simple.txt
>    ftp: //ftpeng.cisco.com/fred/sava/Sava-Simple.xml

This seems to be geared at the 'LAN spoofing prevention', and could be 
used as a more automatic tool for populating link-layer <-> IP 
spoofing prevention inside a subnet.

However, if the router(s) of such a subnet were to apply uRPF on the 
link, the impact (to those outside the subnet) would already be 
eliminated.

As such as this seems to be a more fine-grained solution compared to 
strict uRPF, it doesn't seem to be any easier to deploy than strict 
uRPF.  It also doesn't solve the more difficult inter-ISP problems 
quoted at the BOF.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: fred at cisco.com (Fred Baker)
Date: Tue Mar 20 12:11:14 2007

On Mar 19, 2007, at 9:23 PM, Pekka Savola wrote:

> This seems to be geared at the 'LAN spoofing prevention', and could  
> be used as a more automatic tool for populating link-layer <-> IP  

I certainly agree that switch features along these lines are of  
value. We have a product that has such a feature. One of the comments  
in this document is that not all hosts are on switched networks  
(wireless comes to mind), and that fixing it on the local network  
fixes it everywhere else.

    Implement what amounts to Local Unicast Reverse Path Forwarding.
    Impose a policy that one IP system should accept IP datagrams from a
    directly-connected IP neighbor (host or router) if and only if the
    Source IP Address is among the equivalence class of IP addresses
    known to be associated with the neighboring device.  If traffic is
    not accepted if that fails, this protects the devices each direct
    recipient from the problem.  Since one of those direct recipients is
    the first hop router, by extension this protects the enterprise and
    the Internet.

So to my mind, the last defense of any system is itself, and the host  
itself can choose to not accept spoofed datagrams.

> However, if the router(s) of such a subnet were to apply uRPF on  
> the link, the impact (to those outside the subnet) would already be  
> eliminated.

I like uRPF too. That said, uRPF has a number of issues in a network  
with asymmetric routing, and doesn't protect the neighboring hosts on  
a LAN.

I will repeat the observation that if no spoofed packets can get  
across the first link, there won't be any on any subsequent link either.

> As such as this seems to be a more fine-grained solution compared  
> to strict uRPF, it doesn't seem to be any easier to deploy than  
> strict uRPF.  It also doesn't solve the more difficult inter-ISP  
> problems quoted at the BOF.

My observation (made in the document) is that what was described in  
the BOF - to the extent to which there was an algorithmic description  
- doesn't meet the first requirement, which is to prevent spoofed  
addresses in the first packet.

I submit that for the inter-ISP problem, you need a variant on the  
"evil bit".

	http://www.ietf.org/rfc/rfc3514.txt
	3514 The Security Flag in the IPv4 Header. S. Bellovin. April 1 2003.
	     (Format: TXT=11211 bytes) (Status: INFORMATIONAL)

You want some flag either in the packet or derived from routing in  
which an ISP that believes that some of its peers apply uRPF or  
ingress filtering to their customers marks those that don't, with a  
view to discarding their traffic first in the event of a ddos attack.

The last thing you want, I think, is an optional negotiation. Being  
optional, I have to believe that the bad guys won't do it or will use  
it as an attack. Being a negotiation, it is something that has to be  
done prior to the other communication, and can itself carry a spoofed  
address.

---

From: miw at computer.org (Mark Williams)
Date: Tue Mar 20 23:07:37 2007

Fred,

Something quite similar to this was proposed as a straw-man solution for 
the access network. The proposed solution deals only with LAN networks.

see section 3.3 of draft-wu-sava-testbed-experience-00.txt

Like BCP38, if it were universally applied, either your solution or the 
one in the above draft would be effective. Of course, one of the key 
assumptions necessary to establish the need for SAVA or something like 
it is that we do not have universal application of edge spoofing 
protection, nor are we likely to achieve such without doing something 
away from the edge.

cheers,

Mark

Fred Baker wrote:
> I certainly agree that switch features along these lines are of value. 
> We have a product that has such a feature. One of the comments in this 
> document is that not all hosts are on switched networks (wireless 
> comes to mind), and that fixing it on the local network fixes it 
> everywhere else.
>
> _______________________________________________
> SAVA mailing list
> [email-masked]
> http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava
>