[nsp] bgp vulnerability?

[David Flynn]

* Dmitry Volkov (dmitry.volkov at rogers.com) wrote:
> [snipped and rearranged]

> Am I wrong here ?

Yes and no :-)

> I'm just wondering - because it's valid RFC 793 behavior,
> how it can be avoided ?

You are right in that it is valid behavior, so as such you can't avoid
it with plain tcp.  You can do things however to either prevent the
packet getting to the router or prevent the spoofing from being considered
a valid packet (ie you increase the domain of the problem to such an
extent that brute forcing it is not feasable [1])

The options avaliable are:

    1) Use a TCP `extension' called the MD5 Signature option.
       This works by using a shared secret [password] by both parties
       to compute an md5 hash of bits of the header and the secret.
       The sending party sends the hash it computes in the packet
       and the receiving party recalculates the hash and compares it.
       If it doesn't match the packet is discarded.

       This solution is increasing the domain of the values which
       have to be right.  It isn't a perfect solution, but probably
       increases the domain sufficiently to make an attack unlikley
       to succeed.  [This method has been hotley debated in some
       quarters as to it breaking the TCP standard itself by making
       reset too complicated, but that isn't an argument for here]

    2) IPSec, Run the TCP session between the two BGP speakers over
       IPSec, it is encrypted.  This is probably the better technical
       solution, but we don't all run and have no wish to run IPSec
       versions of IOS on our routers.

    3) Filter your core network.  Only certain routers should be able
       to speak with the BGP speaker, other traffic which `looks'
       like BGP but is in the wrong place shuold be dropped.  (eg
       bits trying to enter the core at the wrong router)

    4) Filter your access networks, While this isn't a solution to
       the problem at all, people probably should be filtering access
       networks to stop spoofed packets from ever entering your network
       and even worse getting onto the internet at large.  (okay some
       times it is necessary, but they are the exception to the rule)
       this would also help get DoS attacks onto grounds that we can
       deal with, trace, etc., (again for another time)

    5) Break TCP.  Yes, while possible and even possibly excusable
       you may deliberately missimplement the specification.  Possibly
       not the most prudent move in the world though.


These are most of your options, Because of licenses and people not wanting
to/cant use IPSec, md5 is the simplest and easiest solution for the time
being.  However, 3 & 4 are certainally a very good idea and should be done
anyway.

Enjoy,

..david


[1] The exact analogy is key space in a cypher, you can pick out the key
from a 2^8 bit keyspace relatively easily by testing each combination,
where as with 2^128 bit keyspace you're starting to hit the heat death
of the universe before exhausting it.