Subject: Re: TCP MD5 signature option (RFC2385)
From: Frank Solensky <solenskyf@acm.org>
To: Andi Kleen <ak@suse.de>, Chris Dukes <pakrat@www.uk.linux.org>,
   jamal
	 <hadi@cyberus.ca>
Cc: netdev@oss.sgi.com
In-Reply-To: <Pine.GSO.4.30.0201260817450.4585-100000@shell.cyberus.ca>
References: <Pine.GSO.4.30.0201260817450.4585-100000@shell.cyberus.ca>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 26 Jan 2002 15:25:02 -0500
Message-Id: <1012076731.2212.52.camel@localhost.localdomain>
Mime-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk

> On Sat, 26 Jan 2002, Andi Kleen wrote:
> 
> > TCP is not very well fitted to add a new 'go over all data in packet'
> > pass. It is heavily optimized for copy-csum-and-forget in one go.
> > You could add a new pass for MD5, but it would not be nice.

True -- as you say, it is rather obscure.  When it is used, it's
generally expected that the connection will be slower.  Once the BGP
table feed has completed, though, a stable connection won't send much
more than periodic keepalive messages (but then we all know the
difference between 'theory' and 'practice').

On Fri, 2002-01-25 at 23:17, Chris Dukes wrote:
> 
> I've already asked Frank offline if what he is trying to do actually
> requires linux (The "I need to get this running" factor vs. the "How
> about a little standardization" factor).

And I was probably a bit vague in my response -- more the latter.  I had
been doing some BGP testing a while ago and was using zebra in one of
the peers but couldn't test the authentication option since it's not
currently available.

> Unfortunately, I have no idea if or how AIX,
> HPUX, and Solaris do TCP signatures, let alone if their API
> is similar to the BSD interface.

I sent a query to a friend of mine at Sun earlier today to see if they
do;  my guess is no but we'll see.

> In any case, the average user should almost never need this feature to
> be enabled.

Agreed; I was planning on making it configurable, off by default.

On Sat, 2002-01-26 at 08:23, jamal wrote:
> This is a TCP option; so should fit well in the slow path.
> Of course it brings a whole new meaning to DoS;-> IIRC, not all packets
> within a flow will have this option turned on;

I'm pretty sure when I was looking at the OpenBSD implementation, it was
an all-or-nothing approach: if a socket had enabled the option, a packet
that didn't include the option would be dropped.  Vice versa, also: an
MD5 signed packet sent to a socket that wasn't expecting it causes a
packet drop.
				-- Frank