I'm curious exactly what is the problem definition for SAVA and what is the threat model. One definition is: given an IP packet at a destination AS, determine (at dest AS router?) whehter the packet's source IP address is spoofed. This problem is related to several other problems including DDoS attack, IP traceback, but not exactly the same. The threat model and goals can be different.
There're many types of threats: attackers control end hosts, attackers can sniffer edge router/backbone traffic, attacker control edge router/backbone router. There're different goals as well: simply determine whether the source IP is correct (what action to take is orthogonal), preventing DDoS attack traffic from reaching end-hosts, identifying the true source AS of such packet. As a first step, it helps to clarify exactly what the problem is (and is not), what threats SAVA needs (and need not) to address, what goals it wants to achieve. Fan [EMAIL PROTECTED] wrote on 09/12/2006 10:31:55 AM: > Thank you for your valuable comments. > I am trying to give some explain. > > > > > You should clarify what you mean by 'protection for the routing > > infrastructure'. What are you protecting against? What do you mean > > by 'protect'? What do you mean by 'routing infrastructure' -- all > > routers in the internet, or just the router in a particular service > > provider's network? > > > > In my mind, the goal of SAVA is to provid new mechnisms that can > be implemented in > the network equiments (rather than in the end systems) to > provent source address spoofing. > The word "protect" here means providing a way for spoofing prevention. > Depending on the solutions, the protection could be in different level. > The partial network (One or multiple ISP networks/enterpise > networks ) who deployes SAVA should be protected. > Therefore, providing incentives to deploy and supporing the > incremental deployment (partial deployment still works) and should > be mandoary requirements when we design new solutions. > > > If this refers to ensuring that your own routing infrastructure is > > secure, I argue this can already be achieved by appropriate edge > > filtering at your own borders. See > > draft-savola-rtgwg-backbone-attacks-02.txt and OPSEC WG documents for > > more. > > The doucment is related, but I think the problem we stated in SAVA > is not the goals that thoes document wants to resolve. > (at least in section 1.2 of draft-savola-rtgwg-backbone-attacks-02.txt, > it "assumes that the service provider is doing at least > some form of address filtering at its border devices, i.e., by > ensuring that only the infrastructure nodes can use infrastructure > source IP addresses to talk to the other nodes in the infrastructure. > ". The assuption is exactly the problem we want to resoulve in SAVA.). > > SAVA fouces on IP layer only, aims to reolve source spoofing, then > provide a trustworthy infrastrucure, > DDoS attacks is a cross-layer problems, so the DDoS prevention is > out of SAVA's scope. > But I think outcome of SAVA WG, providing an infrastuure without > source address spoofing, > will defintely help thoes drafts that study how to prevent DDoS on > routers or hosts. > > For the OPSEC documents, see my commets below on ingress filtering and uRPF. > > > On the other hand, if this refers to generic routing infrastructure > > security, it isn't obvious how a source address validation proposal > > would significantly improve the current situation. > > > > > It is not clear what you mean by 'works'. You can protect your own > > infrastructure just fine by applying the protection at all of _your_ > > borders. In most scenarios, that's sufficient, and could be phrased > > as "works". Or do you have "every packet that enters your network has > > a provably correct source address" as a goal here? > > The word "works" here means the edge network that deploys > ingress filtering will be protected. > Ingress filtering only benifits others, unless all edge networks > are deployed, you can't protect yourselve (because you can't make sure > the source address of packets coming from outside world is not > forged). I think this problem is also indicated by OPSEC documents. > > Thelack of incentive will be a key problme for the golabl > deployment of ingress filtering. > Why an edge network deploys ingress filtering to benefit others, > that might be why MIT > spoofer project found lots of ASes are spoofalbe. > > Thus, ingress filtiering is effective on edge network, but doesn't > support the parial deployment and > lacks of the incentives. > > >> b) uRPF does not work well in places where asymmetric > routing happens. > >> This constitutes a large part of the Internet > > > > This is a common misconception. Maybe you haven't seen RFC 3704 (BCP > > 84) which describes how to do it. For more detail, also look at > > draft-savola-bcp84-urpf-experiences-01.txt. > > > I disscussed with Prof. Lixia Zhang on routing table based methods. > We think the routing table bas filitering methods (uRPF and > variations) are somehow dangerous in backbone. > because it depends on the routing related problmes such as > stablization/asymmetrion. > Routing table based forwarding is OK because if a packet is > forwarded to a wroing path, > it still has chances to be forwarded back to the right path by the > next router. > But wrong filtering table will make the packet dropped. > Therefore we think FIB based filtering can resolve part of the > problem , but still doesn't work it all cases. > In SAVA, we hope the WG members can propose some new solutions in > IPv6 to resovle the problem. > > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > > SAVA mailing list > > [EMAIL PROTECTED] > > http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava > > > > _______________________________________________ > SAVA mailing list > [EMAIL PROTECTED] > http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
