[email protected]
[Top] [All Lists]

RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption

Subject: RE: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple AuthenticationOption
From: "Anantha Ramaiah (ananth)"
Date: Wed, 14 Jun 2006 08:55:16 -0700
Lars/Joe : 
   A quick observation :

   IMO we shouldn't tie the TCP MD5 replacement and/or key change
requirements for BGP alone. The TCP MD5 option is also used, although
less "agressively", by other protocols like LDP and MSDP as well.
Whatever solution is going to be devised should benefit other riders on
TCP as well.

> -----Original Message-----
> From: Lars Eggert [mailto:[email protected]] 
> Sent: Wednesday, June 14, 2006 8:21 AM
> To: Ron Bonica
> Cc: [email protected]; [email protected]; Joe Touch
> Subject: Re: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple 
> AuthenticationOption
> 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.
> That has proven difficult, because the different technical 
> proposals are motivated by different sets of requirements. It 
> would be good to come to a consensus on what requirements 
> such a solution should fulfill.
> There is another complicating factor. BGP and TCP are both 
> core protocols of the Internet. I can understand that from a 
> BGP point of view a solution that replaces one non-BGP (i.e., 
> TCP) extension with another is the preferred approach, 
> because it minimizes modifications to BGP. However, the BGP 
> folks need to realize that such approaches have a larger 
> impact on TCP than others, and the TCP folks are likewise 
> rightfully conservative when it comes to changes to TCP.  
> (Especially changes that are only relevant to a single 
> application on top of TCP.)
> Note that I'm not ruling out a TCP-based solution at all. But 
> I'd be much happier if we arrived at such a conclusion based 
> on an open- minded analysis of the pros and cons of the 
> various proposals.
> Lars
> -- 
> Lars Eggert                                     NEC Network 
> Laboratories

tcpm mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>