Yes, I believe SAVA framework would adapt muilti-fence solutions,
to prevent source address spoofing in different granularity (AS, subnets,
hosts).
Regards,
Jun Bi
----- Original Message -----
From: "Fan Ye" <[EMAIL PROTECTED]>
To: "Jun Bi" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Mark Williams" <[EMAIL PROTECTED]>; "Pekka Savola"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL
PROTECTED]>
Sent: Tuesday, September 12, 2006 11:29 PM
Subject: Re: [SAVA] Re: [Int-area] Call For Participation and Interest:
SourceAddress Validation Architecture (SAVA)
> 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
