>>>>> "ap" == Alex Pilosov <alex@xxx> writes: >>>>> "ar" == Adam Rothschild <asr+nycbug@xxx> writes: ap> I'm sorry (for your customers). hah. well, they are quite happy so far. and i'm happy to have discovered this 'bfd' hardware fast-HELLO feature in Cisco. I think it has some real value. I hope I won't have to eat those words. :) ar> Play too much of an active role, and customers will (as you've ar> later commented) complain. That makes sense. I guess there is plenty of this problem in the anti-spam world, also---people complaining about falsely-bounced mail and vindictive blackhole lists. ar> Much of the provider-edge hardware you'll find commonly ar> deployed today simply does not support uRPF, or does so by ar> halving the FIB (or some other equally brain-dead method), I saw that---I think this is one thing which improved on the 6500 from Sup2 to Sup720. but there still seem to be some tricky bits to it---the multipath limitations, and the complicated rule about partial software-switching when you use the ``exempt from uRPF'' access list. ar> ...and when was the last time you saw a multi-gigabit attack ar> where spoofed address space was even a significant factor? well, never---no experience with multi-gigabit attacks at all, so maybe uRPF isn't so important. But I would add (1) it's important for the final architecture to work on attacks that are problems for customers, too, not just the attacks that are problems for ISP's. If we're designing some new architecture, even attacks that are so small you throw your heads back and laugh and say we've ``requested'' the attack ought to be dealt with. And (2) I bet some form of uRPF will be part of a final architecture, that the other pieces won't work well without it. Maybe I'm wrong, but one way this is already happening, uRPF is immediately useful for non-spoofed attacks because you can distribute null routes over iBGP to quickly block by source address at the edge. my first hack at an architecture would be: (1) some ISP's implement the plan, and some don't. (1a) implementing ISP's do uRPF on customers (2) customers of implementing ISP's can request that traffic from a certain IP be blocked, and it will be, but only traffic from that IP _to_ the requesting customer. (3) there's some ACL distribution protocol for pushing out these customer requests. If the source of the traffic is an implementing ISP, then that ISP must accept the request and block traffic at the source. the traffic-source ISP will validate requests, and only take add-ACL requests with destination IP's advertised into BGP by the AS submitting the add-ACL request. ACL's time out after a couple hours. (4) if the source isn't advertised by an implementing ISP, and the requesting customer doesn't have any incompetence/maliciousness points against him, the source IP is advertised over eBGP among implementing ISP's as a null route, and now ALL traffic from that IP passing through any implementing ISP, even traffic to non-implementing destinations, is blocked, not just traffic from that IP to the requesting customer. (5) some kind of much more complicated uRPF to defend implementing ISP's against non-implementing ISP's trying to spoof traffic sourced from a prefix advertised by an implementing ISP. This may be best-effort, and needs the most further thought and is probably more than a SMOP. the incentive to become an implementing ISP is: (a) prebuilt tools you can offer customers to do (2), (b) less DDoS flowing over your links because you gain the right to submit ACL's and null routes to at least _some_ other ISP's (c) you won't have to worry about being blocked by uRPF/BGPnull in (4), so you can sell customers more reliable access into and through the clan of implementing ISP's Obviously there's a lot to work out in this architecture. For example the ``source'' AS may be a multi-homed customer who isn't implementing the scheme. The scheme should be ready to send ACL-add requests in (3) at least one hop up in the AS path (if not even to any hop along the AS path), to at least try to reach the multi-homed customer's ISP before fully-blocking him with (4). so hopefully the great minds already working on this are way ahead of me. The last thing I heard on the topic was this uRPF/BGPnull thing, which is really not very far along. I think the hardware is getting closer, though, at least ASIC-wise.
Attachment:
pgpZ26Cj6PtBf.pgp
Description: PGP signature