RE: TCP/BGP vulnerability - easier than you think

["David Luyer" <david () luyer net>]

Paul Jakma wrote:
> On Wed, 21 Apr 2004, Iljitsch van Beijnum wrote:
>
> > On 21-apr-04, at 21:17, Paul Jakma wrote:
> >
> > > > I'm not recommending this for "small" peers as the crypto DoS risk
> > > > is worse than what happens when the attack is executed
> > > > successfully.
> >
> > > Why would MD5 be more of a crypto DoS risk with IPSec AH headers than
> > > with bgp tcp-md5?
> >
> > Beats me. But why do you bring up IPsec?
>
> The paragraph is quoted is your advice against using IPSec, I dont
> see why an MD5 auth header IPSec protected sessions would have more
> risk of crypto DoS than compared to the simple BGP TCP MD5 hack. The
> risk is due to MD5, not IPSec :).

Seems like an easy question to me - with the MD5 auth header, you have
the option of validating all the (plaintext, err, plainbinary?) header
components (ips, ports, sequence, etc) before checking the MD5 sum.

So if properly implemented, the MD5 overhead would only be incurred
if the packet was already capable of corrupting the BGP session.

When combined with the TTL sanity check (which has potential flaws
around TTL misgeneration/miscalcalculation eg 255 vs 254, hops which
don't decrement TTL eg some MPLS routers and a very small portion of
IP switch-routers and cases which it can't be used such as iBGP and
multihop eBGP) this would provide a very secure system, if the MD5
is done _after_ TTL, ip, ports, sequence, etc.

With ipsec, you have crypto overhead before you have any opportunity
to do the basic sanity check.

> > Anyway, what needs to happen is a form of crypto where the
> > expensive algorithms are only executed for good packets and not for
> > all packets.
>
> So configure ipsec to authenticate packets between the peers allowing
> only md5 or somesuch. I dont know about other IOS, but other
> implementations do allow one to specify security associations on a
> per port basis.

A static ACL would not be granular enough in specifying valid packets
to prevent crypto being executed on spoofed packets in the ipsec case.

David.