Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP SimpleAuthentication Option

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 14 Jun 2006 15:40:26 -0700

Anantha Ramaiah (ananth) wrote:
> Just one comment inline...
> 

>> 
>> There is some merit to applying stare decisis here, and keeping
>> TCP-MD5 functionality but allowing a new hash to be used. To the
>> extent that we keep this funcitonality as an interesting footnote to
>> the TCP roadmap (ignored by almost all
>> implementations) then I think Joe's proposal is the correct way.
>> 
>> TCP option space is a scarce resource. It should not be used for
>> features that are better solves above or below the transport layer.
> 
> TCP option space is limited is a well known thing. However
> this should not be a reason to preclude anyone from not
> inventing new TCP options.
> If the TCP option space is limited then let's fix it. [ There
> are atleast 3 proposals on table which needs to be discussed
> including the recent one from from Mark Allman to address the
> TCP option space expansion]
> 
> There are a wide variety of applications riding on top of TCP
> and as the internet evolved new requirements began to crop up
> and it is not always easier to move to a newer transport
> protocol (nice thing to do but not always feasible). There
> keeps coming some generic requirements in terms of connection
> security, connection persistence, connection tuning etc.,
> which warrants the need for newer TCP options. However in
> most cases these newer TCP options never make it to standards
> and end up being proprietary or some other poorer
> alternatives sought.. I don't have the complete list, but I
> have seen this happening.
> 
> But I also do understand that the TCP option space should not
> be exploited for doing things that are better done in other layers.
> 

It is not as though TCP options are harmless pass-throughs that
have zero impact on TCP stacks. TCP-Auth, for example, breaks
LSO because you cannot calculate the hash before the message
is segmented. And you will not see TCP-Auth getting hardware
support because it has to get in line behind IPSec.

Transport options can indeed be somewhat specialized, but they
should at least be solving transport problems.

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2006 22:36:40 -0700

> should at least be solving transport problems.

Transport hardware can also be specialized, but should solve the needed
transport problems. If you have a TCP implementation that supports
TCP/MD5, TCP-SA, or TCP-Auth, then LSO hardware ought to support that
option or disable LSO on those connections.

Joe