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

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 12 Jun 2006 13:45:37 -0700

Andrew Lange wrote:
> Hi Joe,
> 
> The main reason for the TCP extended auth proposal is the
> ability to rollover keys without taking the session down.
> Adding additional, more secure algorithms is a secondary goal.
> 
> A key attack vector our customers are concerned about is the
> disgruntled employee let go or other compromise of the key list.
> They need to be able to change the keys without interrupting
> the session and causing routing to suffer.  Without this, a
> new mechanism is not particularly useful.
> 

Something about "disgruntled employee" sounds distinctly
application domain to me.

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Jun 2006 13:49:26 -0700

> application domain to me.

Yeah - and one would hope that wouldn't be frequent enough to design
protocols around either ;-)

Joe

---

From: Andrew Lange <[email-masked]>
Date: Tue, 13 Jun 2006 15:22:19 -0700

Joe, Caitlin,

What we do have to design protocols around is user requirements.  We  
also have to design protocols with maximum flexibility and  
robustness.  End users will use the protocols in ways we haven't  
predicted to meet requirements we don't yet know about.   All TCP EXT  
AUTH does is provide a way to authenticate TCP sessions.  It is  
radically more simple and easier to do this at the TCP layer than to  
implement something slightly different across a variety of higher- 
level routing protocols.

Andrew

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 Jun 2006 15:33:02 -0700

Andrew Lange wrote:
> also have to design protocols with maximum flexibility and robustness. 
> End users will use the protocols in ways we haven't predicted to meet
> requirements we don't yet know about.   All TCP EXT AUTH does is provide
> a way to authenticate TCP sessions.  It is radically more simple and
> easier to do this at the TCP layer than to implement something slightly
> different across a variety of higher-level routing protocols.

Those modifications are already underway or implemented in the primary
protocol of interest (BGP). These modifications reflect (IMO) an error
in protocol design: TCP connectivity was never intended to reflect path
viability for routing. Interpreting TCP disconnects as a path failure -
which is the only reason to flush the associated routes - is thus an
error which it is appropriate to correct.

If that's not sufficient, it would be very useful to understand why
IPsec isn't more than sufficient to solve the user protocol requirements
here.

If there are needs beyond the protocol level - e.g., anything involving
disgruntled employees fits in here - then it'd be useful to understand
why a protocol solution is necessary.

Joe

---

From: Mark Allman <[email-masked]>
Date: Tue, 13 Jun 2006 18:50:40 -0400

Andrew-

As a still-puzzled observer...

> requirements we don't yet know about.  All TCP EXT AUTH does is
> provide a way to authenticate TCP sessions.  It is radically more
> simple and easier to do this at the TCP layer than to implement
> something slightly different across a variety of higher- level routing
> protocols.

Isn't this shove-it-down-into-a-common-place-in-the-stack-such-that-it-
is-"radically more simple easier" notion one of the reasons we ended up
with IPsec at the network layer?  And, don't routing protocols generally
use IP (at least those that use TCP)?

In the above you argue for generality.  I buy that.  But, why don't we
use the general notion that has been developed for hardening TCP/IP
traffic (IPsec)?  Why should we do something different in this case?

allman

---

From: Ron Bonica <[email-masked]>
Date: Wed, 14 Jun 2006 09:36:29 -0400

Joe,

I think that you are invoking a very old argument regarding BGP. That
is, that a TCP connection failure should not be interpreted as a path
failure and, therefore, should not cause routes to be withdrawn.

You may or may not be right regarding this issue. However, the point is
moot. For better or worse, that decision was made years ago and BGP
became the infrastructure upon which interdomain routing is based. This
isn't about to change any time soon.

Given that BGP is what it is, we would do well to enhance TCP to support
its current requirements.

                                      Ron

Joe Touch wrote:
> ------------------------------------------------------------------------
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2006 07:10:31 -0700

> isn't about to change any time soon.

It is already changing, if it hasn't already - the relevant IDs are
cited in my draft.

> its current requirements.

Sorry, but that's nonsensical; you're asserting:

	- BGP is as it is; we can't change it

	- TCP needs to be modified

I hope you can see why - if anything - the converse will always occur
first. BGP isn't the only user of TCP.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Wed, 14 Jun 2006 18:21:13 +0300

Hi,

> 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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 14 Jun 2006 18:21:13 +0300

Hi,

Lars

---

From: Andrew Lange <[email-masked]>
Date: Wed, 14 Jun 2006 13:26:22 -0700

Hi Mark,

I'll try to answer your questions below.

On Jun 13, 2006, at 3:50 PM, Mark Allman wrote:

>> robustness.

Typically, yes.  There are some routing protocols (ISIS) that don't  
use and IP layer, but those are out of scope for this solution.   
We're targeting TCP-based routing protocols specifically here.

> traffic (IPsec)?  Why should we do something different in this case?

IPSec is certainly an option.  There are a lot of good things about  
IPSec.  But, there are some shortcomings which have prompted  
operators to ask for a simpler mechanism.  Some of these are:

o DOS vulnerability on existing hardware.  We want to improve  
security without requiring a wholesale swap of all the router control  
planes out there.
o Cannot support pre-shared key rollover with the session up. - Here  
some explanation may be required.  Certificates aren't an option  
because of the root trust problem between operators.  So psk mode  
would be used.  Rollover of this psk is desired.  We cannot do this  
with IKEv2, and can only do this with IKEv1 using a bit of a hole in  
the protocol between session rekeyings.
o IPSec is _perceived_ to be very complex, difficult to configure and  
maintain.

With TCP Auth we will have another tool in the toolbox.  This will  
help us improve security across the 'net.  It is not intended to be  
the only tool that can be used, just one that will be easy to deploy  
and raise the security wall that much higher.

Andrew

---

From: Andrew Lange <[email-masked]>
Date: Wed, 14 Jun 2006 13:14:08 -0700

Hi Joe,

On Jun 13, 2006, at 3:33 PM, Joe Touch wrote:

>> provide

I would encourage you to participate in the routing research efforts  
related to long term improvements in the global routing architecture.

> IPsec isn't more than sufficient to solve the user protocol  

There is nothing about TCP Auth that precludes the use of IPSec.

The TCP Auth mechanism simply provides an important enhancement to  
existing security options.   There is clear demand from people who  
run networks for a simple, re-keyable authentication mechanism for  
routing protocols.  This fills that niche.

If an operator wants IPSec, with the tradeoffs that means, they can  
use it.   I think we can all agree that IPSec is not the end-all be- 
all of security.   It is a good tool to have in the toolset, but not  
a miracle-wrench that fits all applications.  TCP Auth provides  
another tool for these applications.

> why a protocol solution is necessary.

Protocols are designed to provide functions for networks operated by  
people.  The imperfection of human nature and organization requires  
that protocols support that imperfection.  Almost any aspect of  
security needs to look at the whole threat model and do what we can  
to mitigate it.

Andrew