Subject: [tcpm] security draft input request

From: "Charlet, Ricky" <[email-masked]>
Date: Mon, 3 May 2004 13:45:55 -0700

Howdy,

	I've just joined this list because of specific interest in
draft-ietf-tcpm-tcpsecure-00.txt.

	I browsed the archives so far on this and feel that TCPM will
achieve a consensus solution in about a year if at all. (don't take that
as meanness on my part, I know the pain of moving discussions forward in
IETF).

	With regard to Mark Allman's request about which direction to
head off in (menu choice of options...) could I chip in this idea:

	Do draft-ietf-tcpm-tcpsecure-00.txt as an informational RFC and
all its patches to be included under a socket option. That way the
application has control of if the new behavior is on/off and can make
interoperability/security tradeoff decisions based upon its own
particular environment. Then this WG can collect field experience and do
a standards track RFC at a more realistic pace.

	If anyone cares about were I am coming from... I am the network
protocols engineer for a small commercial RTOS. Some of my customers
have applications (other than BGP) which do in fact rely on long-lived
TCP connections. They've read the news. They've assessed their
application's (real) vulnerability. They want a patch yesterday. I want
to satisfy them but not move so far out ahead of IETF that I get my
branch cut off behind me. 
	
	Therefore, I'm tossing the idea of a two track pace out to this
working group. Do something quick and informational under a socket
option and figure out the wise path at a normal pace.

---
Ricky Charlet
[email-masked]
USA 831.466.4968

-----------------------------------------------------------
Unless otherwise expressly stated, this message does not
create or vary any contractual relationship between you and 
ARC International.  The contents of this e-mail may be 
confidential and if you have received it in error, please 
delete it from your system, destroy any hard copies and 
telephone the above number.  Incoming emails to ARC may be 
subject to monitoring other than by the addressee.

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

---

From: Mark Allman <[email-masked]>
Date: Tue, 04 May 2004 12:06:48 -0400

> I think that minor TCP updates for security will give a false sense of
> security (no pun intended) and will need constant revision as
> attackers undoubtedly will outsmart the fixes.  I'm sure that the
> entire internet cannot update its TCP stack for every new threat.

I agree with this statement.  But, from the analysis in the i-d it would
seem as if the technique makes these blind attacks quite hard.  Do you
have further thoughts into the vulnerability of the proposed scheme?  If
you do, I think that would be very useful to hear.

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

---

From: [email-masked]
Date: Wed, 5 May 2004 13:48:54 -0500

[Few late comments...]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Christian Huitema
> Sent: 03 May, 2004 1:40 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [tcpm] security draft input request
> 
> 
> > Option #2:
> > 
> >     Document the problem and the existing techniques that 
> can be used
> to
> >     mitigate the vulnerability.  I.e., spell out the attack and that
> one
> >     could use IPsec or the MD5 option to reduce (or eliminate) the
> >     vulnerability.
> 
> The MD5 option is specific to BGP, and should not be mentioned in a
> generic TCP document. The proper mitigations are:
> 
> 1) Use IPSEC: this entirely eliminates the attack, including when the
> attacker is on-path.

I would agree that IPSec will solve the problem in principle, but in practice that requires every TCP host (interested in preventing DoS attacks) to have some form of PKI dependent credentials. This might be okay for BGP router vendors if they have a vendor defined CA just for this purpose, but it's not a valid option for every host on the Internet. And even if it were possible to provide these credentials, people would need to buy expensive new certificates (at least home users) just to prevent some simple attacks every couple of years.

I guess key-exchange (and the associated delay--typically 2 round trips on top of TCP) is what makes IPSec less attractive to me. And without a proper key exchange, it's practically impossible to prevent such attacks. For example, establishing a session key using a well known long term key will not work to prevent such attacks. An attacker who can find the IP address of BGP hosts, can also establish an IPSec session with one of the BGP hosts and send a Tunnel mode packet with the RST packet in the tunnel part. Most IPSec policies will gladly send this packet to TCP layer which will close the connection. (Of course with proper key exchange, this is not a problem.)

So although I don't fully agree with the "Secure TCP" draft, I think it's better for TCP to have its own mechanism.

Yogesh