[nsp] MD5 causes bigger problem than it fixes?

[Niels Bakker]

* rubens at email.com (Rubens Kuhl Jr.) [Wed 21 Apr 2004, 22:44 CEST]:
[..]
>> 2) Presuming:
[..]
>>    - application of filters on my network either being dangerous
>>      due to Ciscos being unable to do line rate ACLs, or not helpful
>>      because they can't drop the relevant packets,
> 
> Is MAC-based filtering being considered at IXPs ? BGP packets from one
> peer shouldn't come from other MACs.

IXPs already filter on MAC address, to avoid loops (which is the surest
way to kill any broadcast medium).

BGP packets from one peer can definitely come from another peer.
Consider the following:

+-----------+   +-----------+
|    AS1    |---|    AS1    |
|  router1  |   |  router2  |
+-----------+   +-----------+
         \        /
          \      /
        +----------+
        | exchange |
        |  v. big  |
        | ethernet |
        |  switch  |
        +----------+    
              \
               \
          +-----------+
          |    AS2    |
          |  router1  |
          +-----------+

AS1 peers with AS2 over the exchange switch.  There is a full BGP mesh
(router1.AS1 and router2.AS1 talk iBGP, and each talk eBGP to
router1.AS2).

Now, the link between router1.AS1 and the exchange switch fails.
router1.AS1, duly configured with "bgp fast-external-rollover" (still
the default in IOS last I checked), sends a BGP cease message and closes
the session with router1.AS2.

router1.AS1 lost its directly connected route to the exchange fabric but
it still gets that route from router2.AS1 (via BGP or OSPF or whatever).
So it has a place to send those updates, and router2.AS1 should forward
them, as the exchange IP address of router1.AS1's interface is one in
use by AS1 and should therefore be accepted on the inside interface, and
uRPF-loose won't drop the packet either.

Don't tell me this doesn't happen this way as I saw it happen this
morning shortly after 5AM... :)

Generally speaking, IXPs can't filter on IP address because they are not
privy to the agreements between different connected parties and thus
can't tell what should be accepted.


>>    - I'd really like something better than "have your upstreams
>>      filter,"
>> is there a solution to protect against this issue?
> BGP-over-IPSEC ?

Same CPU issue as MD5, is it not?  For directly connected sessions
there's the TTL hack (if Juniper implements it soon too, at least).

No router is bad at dropping packets, but performance, as always, varies.


	-- Niels.

--