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
>_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
