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

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 14 Jun 2006 09:08:50 -0700

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.

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 14 Jun 2006 13:57:13 -0700

Andrew Lange wrote:
> Hi Mark,
> 
> I'll try to answer your questions below.
> 
> 
> On Jun 13, 2006, at 3:50 PM, Mark Allman wrote:
> 
>> 
>> Andrew-
>> 
>> As a still-puzzled observer...
>> 
>>> 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.
>> 
>> 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)?
> 
> 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.
> 
>> 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? 
> 
> 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.
> 

Extra TCP Options are not "just another wrench" in the toolbox.

If TCP-AUTH were ever to be truly treated as part of TCP then
it would be a lot of extra work for all TCP implementations
because its interoperability with all other TCP Options would
have to be validated. The fact that it is a large option makes
this problematic.

One goal of standardization is to allow implementers to focus
their efforts on an agreed set of techniques. The consensus on
providing secure communications is IPSec. We should be encouraging
high quality implementations of IPSec by steering application
layers to use it. If there is a feature missing, such as pre-shared
key rollover, then it should be improved in IPSec rather than 
creating an entire parallel mechanism (which won't be generally
implemented) just to add one feature for a very small set of
applications.

The same applies to the configuration and maintenance. It would
be absurd for the IETF to require a certain level of configuration
complexity in IPSec "for security" and then decide that said 
procedures were too onerous for the routers to use. If the
security is truly required then why make the routing system
the weakest link? If it is not required, why burden all the
other applications? In either case that should be discussed
in a security forum, not a TCP forum.