public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: Willy Tarreau <willy@w.ods.org>
Cc: Miquel van Smoorenburg <miquels@cistron.nl>,
	linux-kernel@vger.kernel.org
Subject: Re: TCP-RST Vulnerability - Doubt
Date: Mon, 28 Jun 2004 21:26:07 +0200	[thread overview]
Message-ID: <87vfhbjxgw.fsf@deneb.enyo.de> (raw)
In-Reply-To: <20040628183709.GL29808@alpha.home.local> (Willy Tarreau's message of "Mon, 28 Jun 2004 20:37:09 +0200")

* Willy Tarreau:

> On Mon, Jun 28, 2004 at 01:22:37PM +0000, Miquel van Smoorenburg wrote:
>> 
>> MD5 protection on BGP sessions isn't very common yet.
>
> The Cisco routers we deployed 3.5 years ago were already configured with MD5
> enabled on BGP, this was on IOS 12.0 at this time. And I guess that Cisco
> still has a good share amongst the BGP setups.

Software deployed /= configured & enabled.

One of the main problems with the TCP MD5 option is that it requires a
password which has to be negotiated by the peers.  This adds a
non-trivial management burdern.

> MD5 is not that much expensive. I even wonder if all those new routers
> with VPN hardware acceleration, MD5 could not be computed in hardware
> at nearly no cost.

If the packet is still handled by a real CPU (which is very likely the
case given the complexity of the protocols involved), it will still
overload.

> But the real problem is that the provider should do the
> anti-spoofing himself and not accept BGP packets from the wrong NIC
> ! And it's relatively easy to show them where they're bad.

In this case, the anti-spoofing has to happen at the other side, to
protect you.  There is an anomaly in Cisco ACLs you could exploit to
implement this without too much management overhead, *but* filtering
on core routers still problematic.

However, experience tells us that there is little incentive for others
to invest some work to protect you, and that it doesn't happen in
general. 8-(

  reply	other threads:[~2004-06-28 19:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-25 21:20 TCP-RST Vulnerability - Doubt saiprathap
2004-06-25 22:05 ` David S. Miller
2004-06-26  2:22   ` Andre Tomt
2004-06-28 19:18     ` Florian Weimer
2004-06-28 13:22   ` Miquel van Smoorenburg
2004-06-28 14:49     ` Chris Wedgwood
2004-06-28 18:34     ` Florian Weimer
2004-06-28 18:37     ` Willy Tarreau
2004-06-28 19:26       ` Florian Weimer [this message]
2004-06-29 20:03         ` Valdis.Kletnieks
2004-06-29 21:22           ` Florian Weimer
2004-06-29 21:45             ` Valdis.Kletnieks
2004-06-29  2:34     ` Daniel Roesen
2004-06-29 21:28       ` Florian Weimer
2004-06-29  2:34   ` Lincoln Dale
2004-06-29 21:27     ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vfhbjxgw.fsf@deneb.enyo.de \
    --to=fw@deneb.enyo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miquels@cistron.nl \
    --cc=willy@w.ods.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox