Subject: RE: [tcpm] security draft input request

From: "Christian Huitema" <[email-masked]>
Date: Sun, 2 May 2004 23:39:52 -0700

> 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.
2) Use a security protocol over the TCP connection, such as SSL, TLS, or
application specific security protocols (e.g. MD5 signature of BGP
packets): this mitigates the risk of data injection, but does not
mitigate the denial of service attacks.
3) Randomize one of the two port numbers used in the TCP connection,
generally the calling port: proper randomization effectively mitigates
the attacks by making them less interesting than alternative DOS
attacks, unless the attacker is on-path.

> Option #3:
> 
>     Document the problem, the existing mitigations, as well as
exploring
>     additional mitigations.  Note that this "exploration" leaves open
>     the possibility that we will find no mitigations that have
>     consensus.  If that is the case, then this option basically
becomes
>     option #2 (possibly with some additional thoughts from this group
on
>     why we didn't like anything else in the solution space).

I believe we should do option 2 in any case, i.e. document how a proper
use of TCP can reduce the vulnerability. Since few applications are
actually at risk, we should recommend that applications that are at risk
implement the simple fixes (IPSEC or port randomization). This will
defuse any sense of urgency, and give us time to agree on any fixes to
the TCP protocol.

-- Christian Huitema

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

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 03 May 2004 11:17:29 -0400

Christian:

I have a question about random ports... I have been
told that some ACL/Firewalls will block out ranges of ports
for peers to get through on (this seems a bit hard from me
to accept so I have sent a email to the source of the news
asking for clearification)... if this is true then  randomization
of ports would be interfered with by middle boxes as well... sigh..

Have you heard of such a thing happening in the world ...

Coding for middle boxes in an end2end protocol... gee seems like
fun dosn't it :-0

R

-- 
Randall R. Stewart
ITD - Transport Technologies
815-477-2127(o) or 815-342-5222(c)

---

From: Anantha Ramaiah <[email-masked]>
Date: Mon, 3 May 2004 09:25:57 -0700 (PDT)

> Coding for middle boxes in an end2end protocol... gee seems like

It does sound funny.  If the middleboxes chose to ignore the e2e changes, then
I wonder it is whose problem? TCP was not written to take into account
the middlebox compatibility, it is the other way round.
:)

-Anantha