Re: [RPSEC] Re: draft-convery-bgpattack-00

[Sean Convery <[e-mail]>]

On 11/5/02 at 9:38 AM, [e-mail] wrote:

SNIP
>> - Enterprise BGP Implementation - as a side rant, much of the
>> conversation I've seen on idr and rpsec seems to assume an ISP
>> deployment.  BGP is used plenty in enterprise environments as well.
>> Here MITM, sniffing, etc. become much more possible.
>
>But enterprises aren't typically in the position to propagate much
>malicious routing information as their ISPs filter them.
>
Right, but they are more than capable of being hacked on the inside
(regardless of filtering), which is one of the things we should be
concerned about.

SNIP
>> The easiest way we've come up with to do the analysis would be to
>> assign attributes to various parts of the tree based on different
>> topologies and attackers.  For more info check out the end of
>> section 1 of the draft.
>
>What I'd like to see is a simple web-based tool that has the tree and
>allows you to add security measures such as anti-spoofing filters, MD5,
>static MAC addresses on exchanges and so on, and then see how many of
>the attacks go away. This could be a learning experience. Heck, I might
>make something like this.
>
We agree and would love your help. :) Dave Cook is doing some modelling
to create the tree graphically from the source XML file.  We could
probably extend it to do something like this...

>> Regarding MD5, that got its own section 2.1.1.  Any attack against a
>> system employing MD5 would need to first run through that section of
>> the tree assuming the overall attack requires the generation of
>> valid TCP 179 messages.
>
>I don't think this is made explicit in every place.
>
Right, see my previous below response, we're assuming no best practices
in place: 

>> For the entire tree, we assumed no best practices were employed,
>> this would give us a base set of attacks that could then be weeded
>> down based on lots of factors.
>
>You don't mention a list of best practices... It might be good to
>include a list. Actually I've been working on this for a while.
>
I would think best practices for BGP would need to be in a separate
draft.  There are lots of BPs spread all over the web, has anyone
grouped them all together for the IETF?

SNIP
>
>>> 2.1.7 man "in the middle" is not necessary as it is trivial to pose
>>> as the peer router if there is access to all the traffic.
>
>> I'm not sure I understand your comment.  In this attack we're not
>> assuming access to all the traffic.  Here the attacker is trying to
>> send a spoofed BGP message.
>
>For a successful man in the middle attack you must be able to:
>
>AND - sniff original traffic
>    - inject replacement traffic
>    - block original traffic
>
>However, man in the middle is more difficult to do than simply
>completely assume the identity of the neighbor and yields no extra
>results.
>
>> This tree shows he can do it one of two ways:
>
>> 1. TCP Sequence # attack + the spoofed BGP message
>
>This will obviously break the existing BGP session pretty quickly and
>then all routing information (spoofed or otherwise) from this peer is
>removed.
>
Again, we'd love to test this out. I agree, things could go badly for
the BGP session.
>
>> >If people don't filter properly you can also do very funny things by
>> >routing the BGP next hop addresses into oblivion.
>
>> Can you elaborate on that further?  I think I understand what you
>> are referring to, I'm just not sure where to put it in the tree.  Is
>> this a spoofed message or an intercepted and modified message from a
>> valid peer?
>
>I suppose it could be either. What you do is inject a route that makes
>the next hop address for other BGP routes point to an unexpected
>place. For instance, you can announce the /24 for an IX as two /25s
>with the next hop address set to your router and then you'll receive
>all traffic for all peers connected to the IX. (However, the sessions
>would probably go down in this case.) However, this can be stopped
>with proper inbound route filters.
>
Now I got it.  We do have some info on more specific route introduction,
but it is specific to IGP, We can probably broaden this definition in
2.1.3.

Thanks again,

Sean
_______________________________________________
RPSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rpsec