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

Andre Oppermann wrote:
> Joe Touch wrote:
>> Hi, all,
>>
>> This is, IMO, a signal to review the recommendations in Section 1.1. I 
>> was always concerned that these mitigations would be misinterpreted as 
>> applying to hosts in general, which they do not.
> 
> I do not agree here.  The recommendations in tcp-secure, IMHO, do apply
> to hosts in general and to servers in particular.  Lets have a look at
> some examples:  IRC Servers, Jabber Servers, Usenet/NNTP Servers,
> IMAP Servers, FTP Mirrors (rsync) as well as any other application that
> has long-lived and persistent connections.

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 
of RSTs aimed at a single connection also indicate attacks more 
accurately and sufficiently, even if port randomization isn't used.

>> The document, IMO, is insufficient in indicating therein that:
>>
>>     - with source port randomization, the mitigations are not needed
>>     (port randomization provides a 2^15 strength amplification),
>>     even presuming source IP addresses are known
> 
> Only few do port randomization over the full range.  Most limit it
> to the high or low port range from which the applications draw.
> 
> Lets consider some examples:
> 
> Dest IP and port are pretty much a given.  Source IP is probably known
> to an attacker (like in an IRC or Jabber network).  That leaves the source
> port and seq#.  Lets assume that the source port is in a fairly narrow
> range of a couple of thousand ports either on the low side 1024-5000 or
> in the high range of 49000-60000.  Without full port randomization it is
> likely to be in the early port numbers.  With a window of 64k (2^16) the
> attack space shrinks to 2^16/2 == 2^15 on average.  That's 32k blind RST
> packets per source port.  With larger windows, which become more common,
> even less.  Sounds almost trivially doable.  Seems to me a lot smarter
> to DDoS your favorite IRC network that way than through a traditional
> brute force traffic attack.

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".

Source port randomization, like sequence number randomization, occurs 
once at connection time rather than in the packet processing path, and 
should be recommended anyway.

> The [RST mitigation] ideally, with only rcv_nxt, increases the attack space
> to 2^31.  The three +-1 window approach to somewhere between 2^23 and 2^26.
> 
> [SYN attack] of course is just as evil as RST attack and is completely solved
> by the challenge ACK (at the expense of potential bogus dupe-ack detection
> by the sender).
> 
> [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.

> 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.

>>     - 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.

>>     - 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.

>>     - 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.

> 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.

>>     - the mitigations protect only off-path attacks; on-path
>>     attacks, such as ISPs shutting connections down deliberately,
>>     are not prevented by this mitigation (yes, also noted
>>     in security considerations, but again worth noting in
>>     applicability, and worth adding the ISP example, IMO)
> 
> Of course.  So far nobody implied that it may protect again on-path
> attacker.  Explicitly stating it in the document may no hurt though.

I wasn't suggesting you had implied it; I was just being complete in 
suggestions that would be useful to sec 1.1.

Joe

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

Attachment: signature.asc