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

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Wed, 14 Jun 2006 15:06:56 -0700

Just one comment inline...

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]] 
> Sent: Wednesday, June 14, 2006 9:09 AM
> To: Lars Eggert; Ron Bonica
> Cc: Joe Touch; [email-masked]; [email-masked]
> Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP 
> SimpleAuthentication Option
> 
> Lars Eggert wrote:
> > Hi,
> > 
> > On Jun 14, 2006, at 16:36, Ron Bonica wrote:
> >> Given that BGP is what it is, we would do well to enhance TCP to 
> >> support its current requirements.
> > 
> > I don't think this conclusion necessarily follows. Let me try to 
> > rephrase it:
> > 
> > Given that BGP is what it is (and uses TCP in the way it does), we 
> > would do well to document a way to protect its TCP sessions that 
> > replaces TCP-MD5. (In the short term; in the long term, BGP may 
> > evolve.)
> > 
> > There are several ways to protect BGP's TCP sessions. Not 
> all of them 
> > require extensions to TCP. We need to pick one.
> > 
> 
> I would phrase that as whether BGP's problems should be fixed 
> in BGP or rather they should be fixed in TCP.
> 
> To the best of my knowledge TCP-MD5 is not part of any 
> standard stack. The TCP Option space is simply too limited 
> for it to find it's way into a general deployment where it 
> has to interoperate with other options (such as SACK).
> 
> That means we essentially have a few platforms that have 
> TCP-MD5 enabled and an overwhelming majority where they are 
> not. This forces variations in TCP stacks, divides auditing 
> measures and forces TCP stacks for BGP to be implemented 
> purely in software.
> 
> IPSec is the preferred tool for this problem. By encouraging 
> it's use, rather than carving out a special-use exemptions, 
> we promote development of better IPSec solutions. If BGP has 
> a problem with operational rekeying issues with IPSec then 
> those issues should be raised about IPSec rather than 
> defining a new security protocol.
> 
> 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. 

-Anantha 
> 
> Another option would be for BGP to SCTP and its authentication.
> SCTP control chunks are more extensible than TCP's option 
> space, so the use of one extension does not automatically 
> preclude the use of another.
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tcpm
> 

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

---

From: "Bora Akyol" <[email-masked]>
Date: Thu, 15 Jun 2006 17:30:46 -0700

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

Ahem, IPSEC already supports rekeying ;)