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

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
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.

$0.02,
-Anantha
> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Wednesday, June 14, 2006 8:21 AM
> To: Ron Bonica
> Cc: [email-masked]; [email-masked]; 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-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Lars Eggert <[email-masked]>
Date: Wed, 14 Jun 2006 19:04:49 +0300

> Whatever solution is going to be devised should benefit other  

Valid point. Let me rephrase

>> application on top of TCP.)

as:

Especially changes that are only relevant to a small number of  
applications and a very, very small number of overall TCP connections.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Lars Eggert <[email-masked]>
Date: Wed, 14 Jun 2006 19:06:47 +0300

> applications and a very, very small number of overall TCP connections.
                   ^^^^^^^
                   fraction

Lars

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2006 09:08:04 -0700

> Whatever solution is going to be devised should benefit other riders on

Agreed, which is why LDP and MSDP may need similar graceful restart
mechanisms.

Joe