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

Joe Touch wrote:
> 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 

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

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

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

Care to explain what software a not-brain-damaged host should run to
detect this?  And then what should the reaction be?  Shutting down the
connection?  I don't think so.  There is no counter-measure after you
have detected a RST or SYN flood.  What is one supposed to do?  Filter
these malicious packets?  How?  How can I differentiate them?  Which
brings us back a full 360 to tcp-secure.  Ain't it so?

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

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.

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

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 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 -->here<--]

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

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

>> 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.
And how long will it take until all major vendors support it in their
production ready and stable operating systems?

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

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