[nycbug-talk] [announce] Tonight: NYC*BUG at the Soho Apple Store

[Miles Nordin]

>>>>> "ap" == Alex Pilosov <alex at pilosoft.com> writes:
>>>>> "ar" == Adam Rothschild <asr+nycbug at latency.net> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20070616/983654e3/attachment.bin>