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

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 15 Jun 2006 09:03:53 -0700

Joe Touch wrote:
> Caitlin Bestler wrote:
>> 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.
> 
> 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

Correct.

But proliferating options that serve no general purpose transport
need only adds to the laundry list of things that must be checked.
If these were solving true transport problems, even if specialized,
that would be justifiable. Instead you have a small set of applications
that are shoving their problem down into the transport layer where all
other applications have to pay for them to at least the extent that
more asterisks must be added to the spec sheets (All RFCs supported
except ...). Clutter has costs, even when each item appears minor.

My real problem here is twofold. First, accepting proposed options
as benign on the assumption that they won't be implemented is a
bad idea -- especially when the rationale smells of "it' easier
to get rekeying from TCPM/TSVWG than from a IPSec group.".

Secondly, this is not an "option". The post I was responding to
seemed to imply that options should be fairly simple things for
even an embedded stack to just 'pass through'. An auth "option"
has a value that is calculated *after* the TCP payload is formed.
And once rekeying is enabled it becomes an alternate stream within
the TCP connection.

Options that are phased in over time make sense, options that will
never be implemented except by a distinct minority of stacks are
a totally different matter. Taking such an option and making it
*more* complex, and hence even less likely to ever be implemented
outside of its niche, makes suggeseting a shift to several other
strong alternatives (such as IPSec) look preferable. But at the
minimum, we should do no more than allowing the hash algorithm
to be updated along the lines of your alternate proposal.

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Jun 2006 09:09:31 -0700

> need only adds to the laundry list of things that must be checked.

No disagreement here. My only issue is that LSO implementations
necessarily support the options their upper stacks support. Otherwise
you have a bad TCP implementation.

LSO is not a 'standard' that we need to decide how to interoperate with;
it certainly does, though, complicate LSO to add options, especially
unless where absolutely necessary.

...
> And once rekeying is enabled it becomes an alternate stream within

It's a payload dependent option. There are some others (trailer
checksum, although not widely used), while most are not. That's a useful
distinction regarding the interaction between the software TCP and LSO
support.

(i.e., my post was just a clarification on LSO; I suspect we're in loud
agreement otherwise)

Joe