> 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
|