On Tue, 12 Sep 2006, Jun Bi wrote:
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.).
Let me try to help by providing a more detailed listing of why address
filtering is not done in some networks:
a) there is legacy equipment which doesn't have line-rate filtering
capability
b) network is sufficiently large and complex that defining the border
of your network is almost impossible (may apply to some Tier1
networks)
c) setting up some filtering solutions may be error-prone unless
done carefully in some asymmetric/flapping routing etc. scenarios
d) it isn't considered worth the time to do so, unless there is
clearer benefit or e.g. law requirements
The assumption above is written a) in mind. I observe that a) applies
to SAVA as well -- such equipment is not going to have SAVA support
either. So, I'm somewhat skeptic as to whether that situation is going
to change in a foreseeable future by requiring that vendors implement
something else than line rather filtering instead or in addition.
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.
Do you mean 'protected' as in 'every packet received from outside the
network has a provably correct source address' or 'the source address
has not been forged to be one of the network's own addresses' ?
If the former, there is an issue how you deal with the legacy IPv6
deployments which do not support the SAVA architecture (whatever that
would end up being).
If the latter, this can already be achieved by ingress filtering and
it isn't obvious how SAVA would make it easier.
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.
We may have a misunderstanding here, which is why I'd like to use a
more detailed term instead of 'protect'.
Let me make an example how infrastructure access-lists could help (see
draft-ietf-opsec-infrastructure-security-00.txt section 3) in how you
can make sure that source addresses of packets coming from the outside
world do not have _YOUR_ addresses in them (source address may
still be spoofed, but not from your addresses at least, which is
deemed sufficient 'protection' by many):
Network has prefix 2001:db8::/32.
At all of its peer and upstream borders it adds the following inbound
access list: "if source address is in 2001:db8::/32, drop the packet".
At all of its customer borders it either uses the same as above (if
the customers use a different prefix) or only allows the customer's
addresses ("if source address isn't from 2001:db8:cccc::/32, drop the
packet").
As a result, no one is able to send packets to the network
infrastructure (e.g., TCP-RST packets intending to disrupt BGP
sessions) which have a spoofed network infrastructure addresses in
2001:db8::/32.
Therefore the network deploying this protection gains benefit that its
infrastructure addresses cannot be spoofed from the outside.
However, it's true that more extensive spoofing prevention (ensuring
that your customers don't spoof some other address rather than your
own infrastructure) does have a smaller benefit.
Also, this does not provide a proof that any given packet has a
provably correct source address, but I'm not sure if you could
(practically) get there anyway.
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.
I agree that FIB-based approaches may be inappropriate in some
scenarios (for example, when applied between peerings between large
ISPs) especially with regard to stabilization and prefix advertisement
consistency. However, it applies well in typical customer scenarios
(even asymmetric and multihomed).
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
