now let me take a bite at this 
i can see this 'attack' operational against a multihop bgp session that's
not md5'd.
now the question is... would this also affect single-hop bgp sessions?
my understanding would be no, as single-hops require ttl set to 1.
-J
How do you tell an adjacent TTL set to 1 from a TTL set to 5 four hops away?
Owen
All it requires is for the TTL to be 1 (or 0, I can't remember which)
when it's received. Just launch your packets with a TTL of the number of
hops between you and the victim, and that's that bit sorted...
Simon
A huge round of applause for everyone not doing RPF and egress filtering
where it is trivial to do so. You make everyones job that little bit
harder.
You know who you are.
-Dan
i can see this 'attack' operational against a multihop bgp session that's
not md5'd.now the question is... would this also affect single-hop bgp sessions?
my understanding would be no, as single-hops require ttl set to 1.
you can engineer packets to make sure they have the right ttl when they arrive,
ie if your 10 hops away, set ttl to 10 and it will be 1 on arrival 
Steve
ah yes.. forgot about that 
Thanks,
-J
Not if you use the TTL hack.
Seems like that would be much more useful, and less CPU intensive, and less prone to user error, etc., etc. than MD5
What is a typical receive window on a router? I have been told (have not confirmed) it was about 14 bits.
Assuming a well randomized starting sequence number (just give me this one for the moment), and a source port range of ~4K (one of the router vendor's defaults), at 10K pps it would still take ~29 hours on average to guess the proper values for everything necessary to RST a BGP session. (You can see my math at the end. Feel free to correct me if I missed something.)
Hitting a router for a full day at 10K pps is likely to be noticed by most networks. If you would not notice this, perhaps you should change your monitoring?
And, if you twiddle the defaults on the router vendor mentioned above, or you use a different router vendor, substituting "2^16" for "4000" in the paragraph above leads you to ... 19 days? (Someone check my math.
Of course, some of the reports say that ephemeral ports are not well randomized for some router vendors. 
So, while this is an interesting application of technology (if you are a h4x0r k1dd13 :), I think if the router vendors used well randomized ephemeral ports and sequence numbers, and used the full range of ports available to them, most routers will fall over long before someone could guess the proper values and reset a single BGP session. Or at least the owners would notice before the reset succeeded. It would be even better if the receive window was tuned downward for BGP - not like you need a huge window for data transfer when the hosts are directly connected.
Then we could all stop frantically trying to synchronize thousands of keys between thousands of networks, an exercise which is destined to lose some data, and therefore some connectivity.
Patrick W.Gilmore wrote:
i can see this 'attack' operational against a multihop bgp session that's
not md5'd.now the question is... would this also affect single-hop bgp sessions?
my understanding would be no, as single-hops require ttl set to 1.you can engineer packets to make sure they have the right ttl when they arrive,
ie if your 10 hops away, set ttl to 10 and it will be 1 on arrivalNot if you use the TTL hack.
Seems like that would be much more useful, and less CPU intensive, and less prone to user error, etc., etc. than MD5
But it has limited effectiveness for multi-hop sessions. There is the
appeal of a solution that does not depend of the physical layout of the
BGP peers.
Nope. I won't give you that one, because that's a big chunk of the
problem:
http://lcamtuf.coredump.cx/newtcp/ (one year later)
http://razor.bindview.com/publish/papers/tcpseq.html (original paper)
It seems that Cisco has its act mostly together, but a *LOT* of other
vendors don't, even a year after...
Does MD5 open the door to cpu DOS attacks on routers though? Eg can
someone craft a DOS attack to take out the CPU on a router by forcing it
to MD5 authenticate torrents of junk packets, using less bandwidth than
it would take to DOS the links themselves?
As has been pointed out, blind attacker needs to guess the source port as
well, which would seem to multiply the search space blind attackers need
to hit (the tcpsecure paper states as much - "assuming the attacker can
accurately guess both ports")
Are such attacks still practical in that light?
-Dan
What is a typical receive window on a router? I have been told (have not confirmed) it was about 14 bits.
Cisco routers have a command that will show you this number. It's generally just under 16k. Unfortunately, some looking glasses allow anyone to execute this command...
(Someone check my math.
I think your math computes. I was worried for a moment that TCP might be tricked into emitting a packet when you hit the right port combo but the wrong sequence number. It does, and even helps out by sending back the right sequence number. But of course this packet goes to the real correspondent so this shouldn't help the attacker.
Yes it does. About 5 mbit of md5 should peg a juniper at 100% according
to my friend alex. I have not verified this in the lab. I suggest
you try it out.
Also, this is why the GTSM (ttl hack) was written up 
/vijay
vijay gill wrote:
Yes it does. About 5 mbit of md5 should peg a juniper at 100% according
to my friend alex. I have not verified this in the lab. I suggest
you try it out.Also, this is why the GTSM (ttl hack) was written up
So then you're suggesting that the GTSM is the correct work-around?
No, the correct workaround is the
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
draft. MD5 is also the correct workaround. However, neither of the
two protect against what is the most vulnerable thing in the internet
infrastructure today - a large amount of PPS at the _router_ (with or
without md5 or tcpsecure) will blow it out of the water. A 10mbits/s
of packets at the juniper without md5 will also destroy it.
GTSM protects against that, the fact that it also works against this
is just an unexpected side benefit.
/vijay
To be clear, I was just using jnx as an example. There are very few
currently shipping boxes that will survive a large PPS attack.
(also to be fair, been a while since I verified the above numbers)
/vijay
Dan Hollis wrote:
But it has limited effectiveness for multi-hop sessions. There is the
appeal of a solution that does not depend of the physical layout of the
BGP peers.Does MD5 open the door to cpu DOS attacks on routers though? Eg can someone craft a DOS attack to take out the CPU on a router by forcing it to MD5 authenticate torrents of junk packets, using less bandwidth than it would take to DOS the links themselves?
A reasonable implementation of RFC2385 would only do the cryptographic
MD5 check after matching the TCP 4-tuple and the sequence number. So,
with respect to the attack under discussion, only the packets that would
have succeded in reseting the session make it to MD5 processing where
they then would be dropped.
Still, hitting the TCP stack even without doing the MD5 checks can
kill a router. That's what the TTL hack was suggested for in the first
place.
As has been pointed out, blind attacker needs to guess the source port as well, which would seem to multiply the search space blind attackers need to hit (the tcpsecure paper states as much - "assuming the attacker can
accurately guess both ports")Are such attacks still practical in that light?
Yes. Most OSs do not randomize port numbers, but start at a fixed value
at reboot. On top of that, many do not use much of the 16-bit space
before wrapping. Now add that most BGP speakers don't initiate much TCP
and fire up their long lived BGP sessions at boot time. The search space
is not that big.
Then there's always going to a looking glass and just looking one up.
A huge round of applause for everyone not doing RPF and egress filtering
where it is trivial to do so. You make everyones job that little bit
harder.You know who you are.
well, no, actually, they mostly don't (know).
So all we have to do is apply strong crypto a bit smarter, such that we only burn CPU cycles for good packets rather than for all packets.