Re: [tcpm] Q&C regarding tcpsecure-09 recommendations

Joe Touch <touch@ISI.EDU> Wed, 04 June 2008 23:45 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59483A6810; Wed, 4 Jun 2008 16:45:41 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425003A6810 for <tcpm@core3.amsl.com>; Wed, 4 Jun 2008 16:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvu2mM-V8Ep0 for <tcpm@core3.amsl.com>; Wed, 4 Jun 2008 16:45:32 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B5D0E3A67D1 for <tcpm@ietf.org>; Wed, 4 Jun 2008 16:45:32 -0700 (PDT)
Received: from [127.0.0.1] (32.sub-70-213-140.myvzw.com [70.213.140.32]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m54NjJtA000914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2008 16:45:22 -0700 (PDT)
Message-ID: <4847290E.8070605@isi.edu>
Date: Wed, 04 Jun 2008 16:45:18 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Andre Oppermann <andre@freebsd.org>
References: <48432005.2070201@freebsd.org> <48449321.5000609@isi.edu> <4846FE85.4050009@freebsd.org> <48470E16.5000802@isi.edu> <48471D37.7080107@freebsd.org>
In-Reply-To: <48471D37.7080107@freebsd.org>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0637757738=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Hi, Andre,

Andre Oppermann wrote:
...
>> Long-lived persistent connections are only part of it; that fixes the 
>> destination address and port. The source address and port need to be 
>> known for the attack to be remotely useful. Source port randomization, 
>> in specific, renders the attacks sufficiently unlikely. Detecting bursts 
> 
> This is bandwidth dependent.  May be true today.  But may be not
> tomorrow.  32 bits of address space in computers was deemed sufficient
> for most systems, even larger ones, not long ago...

Agreed. However, first, we're talking about the connection between two 
machines, and the transport bandwidth between them, not just the channel 
capacity. Few machines can sustain more than 1Gbps right now.

Second, all these mitigations become moot if you deploy appropriate 
authentication. They're also moot if off-path attacks are mitigated by 
other means, e.g., path checks and ingress filtering.

>> of RSTs aimed at a single connection also indicate attacks more 
>> accurately and sufficiently, even if port randomization isn't used.
> 
> AFAIK nobody has proposed such a RST detector in any I-D yet.  That
> makes it a moot point.

RST detection doesn't need an ID. It needs a template in SNORT or somesuch.

>> RFC4953 describes this issue in detail, and Figure 1 shows the 
>> required RSTs. Multiplying these numbers by 3,000 (using even just the 
>> low ports), or 15,000 (both ranges) renders the attacks effectively 
>> moot. A few seconds of continuous RSTs or SYNs ought to tip off even 
>> the most brain-damaged host that something is awry, IMO - moreso than 
>> (incorrectly) inferring that RSTs in-window but not at the edge are 
>> "incorrect".
> 
> Care to explain what software a not-brain-damaged host should run to
> detect this? 

Count RSTs received by a TCP that are out of window. If you get more 
than a few (3 maybe), wouldn't you assume someone was trying to attack?

 > And then what should the reaction be?  Shutting down the
> connection?

Ignoring RSTs for some period of time, e.g., a few minutes. That sort of 
thing strengthens the system quite a bit, and ONLY when it is under 
attack. It can be implemented as a filter outside of TCP too.

>> Source port randomization, like sequence number randomization, occurs 
>> once at connection time rather than in the packet processing path, and 
>> should be recommended anyway.
> 
> I don't doubt source port randomization should be used.  I'm arguing
> that your assertion of avoidable implementation complexity is moot.
> The implementation overhead is about the same.  The runtime difference
> is essentially non-existent.

The difference is that picking a random source port doesn't change the 
TCP specification - it's already in-spec. Further, it can be implemented 
in ways that prevent modifying the code all over the place.

>>> [Slipping data] into the window is made way more difficult with the 
>>> ACK check.
>>> Here we go from 2^15 chance at 64k window to 2^32.  Very valuable I'd 
>>> say.
>>
>> Data issues should be, IMO, solved by the use of true security, e.g., 
>> TLS, IPsec, or TCP MD5.
> 
> Careful.  TLS doesn't help here.  It sits above the TCP layer and a
> RST will abort the connection. You will be able to slip data into
> the stream and have it processed but TLS will get out of sync and
> abort the connection.

AOK; if TLS aborts connections due to bad data, then it's a bad 
solution. Fair enough; use IPsec or TCP MD5.

>>> Coming back to the IRC server example an attacker can potentially 
>>> take over
>>> a channel if he manages to insert the right command into a 
>>> client-server or
>>> server-server stream.  For the both the source IP and destination 
>>> IP/port
>>> are known.  To slip a malicious line I simply send a string 
>>> terminating the
>>> previous line and add my line including line ending again.  Then it 
>>> doesn't
>>> really matter which part of the stream I hit.
>>
>> Right - the data attack is more critical anyway. BGP reacts badly to 
>> RSTs (removing routes); other systems just reconnect, so attacks there 
>> have **far** less impact.
> 
> Not true again.  NNTP is just as vulnerable to a connection abort.  Yes,
> it does reconnect (BGP does too) but it has to restart the feed again
> which involves a considerable amount of CPU and disk I/O churn.  On top
> of it NNTP servers run at large bandwidths with large windows.

That's a fine reason to fix NNTP, or to protect it with something more 
appropriate.

> IRC and Jabber servers are not that different.  A net-split when the
> connection between servers is severed is considered very unlucky and
> to be avoided.  It opens the window for all sorts of dirty tricks and
> channel takeovers that can happen during the split.  This is why script
> kiddies so far like the brute force bandwidth exhaustion DDoS attack
> against IRC so much.  Sure it reconnects after some time.  However the
> damage is done with the disconnect.  With Jabber a lot of presence
> information has to be exchanged again like with BGP.

If an app depends that much on a connection staying up, then SECURE the 
thing. All of your concerns point to bad deployment practices.

>>>>     - if source IP addresses are not known, the mitigations are not
>>>>     needed
>>>
>>> For almost all examples above both endpoint plus at least one port
>>> number are known.
>>
>> The lack of the other port number renders SYN and RST attacks much 
>> less likely, and detecting large numbers of such messages would be a 
>> sufficient signal that something is amiss.
> 

[insert magic detection and response system -->snort<--]

Done.

>>>>     - the mitigations may increase the time needed to respond to
>>>>     a legitimate RST, incurring extra RTTs or retransmissions
>>>>     vs. an unmodified system
>>>
>>> Which isn't a terrible price to pay.  As far as my understanding
>>> goes TCP is concerned with reliable transport of data, not absolutely
>>> reliable abortions of the same through RSTs and SYNs.  They do play
>>> an important role in the functioning of the overall system but they
>>> are not sensitive to a delay of a couple of milliseconds.
>>
>> RTTs these days can be upwards of a second or more, esp. when 
>> involving satellite Internet connections, or over some data modems.
> 
> What is lost with a delayed RST vs. a prematurely aborted connection?

Large delays of RSTs can increase the time until new connections can be 
established, e.g., if port pairs are reused (sending a RST does not 
require that either side end up in a TIME_WAIT -- unfortunately).

It's also the additional packets exchanged and the complexity of the 
system that are the issue - notably when an attack is NOT occurring.

>>>>     - the mitigations are not a substitute for network or
>>>>     transport authentication, either of which obviate the need
>>>>     for the mitigations (yes, this is noted in the security
>>>>     considerations, but it's buried w.r.t. applicability)
>>>
>>> There are some problems with transport authentication.  IPSec does
>>> authentication validation before the segment is checked by the TCP
>>> layer. 
>>
>> There's nothing wrong with that; that's its intent.
>>
>>> TCP-MD5 can do better by doing all incoming segment checks
>>> (seq#, ack#, window, timestamps) before doing the MD5 computation.
>>
>> It shouldn't; it should check the validity before checking the 
>> contents.  You're suggesting that packets with bad SPIs be checked 
>> against a particular connection's detailed parameters? Why? If the SPI 
>> is correct, it's a sufficient indication to invest in packet 
>> authentication, since it's as likely to have come from an on-path 
>> attack, in which case any TCP info might be in-spec (even if spoofed) 
>> anyway.
>  >
>>> Nonetheless both can be used for exquisite CPU exhaustion attacks.
>>
>> That presumes software-based crypto. Further, they're not that 
>> exquisite or necessarily CPU-intensive - using IPsec, e.g., requires 
>> guessing the SPI. Tossing packets with invalid SPIs doesn't cost as 
>> much as full validation.
> 
> You're right.  SPI adds 16 bits of entropy before any crypto checks
> are done.  And yes, software crypto is presumed.  As are satellite
> connections and some data modems.

SPIs are 32 bits.

>>> The better my filter is in the TCP-MD5 case, the less exposure a
>>> system has.  Hence I argue that tcp-secure is actually helps TCP-MD5.
>>
>> TCP MD5 is somewhat deprecated (not officially, granted); its 
>> replacement is under development in this WG. One of the key rules of 
>> the replacement is to check the packet's authenticity before doing any 
>> TCP processing.
> 
> Unless some SPI equivalent is included it makes a good attack vector.

The equivalent is source port randomization.

> And how long will it take until all major vendors support it in their
> production ready and stable operating systems?

Port randomization is a lot easier to implement and is already deployed 
(in FreeBSD and Linux, e.g.); see appendix A of 
draft-ietf-tsvwg-port-randomization-01.txt.

Joe


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm