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

[Andre Oppermann <[e-mail]>]

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.

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

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.

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.

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

>     - 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.  TCP-MD5 can do better by doing all incoming segment checks
(seq#, ack#, window, timestamps) before doing the MD5 computation.
Nonetheless both can be used for exquisite CPU exhaustion attacks.
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.

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

-- 
Andre

> It seems like these ought to be added, in light of the note below.
> 
> Joe
> 
> Andre Oppermann wrote:
>> I'm reworking/refactoring/rewriting the FreeBSD TCP input path (in a 
>> separate
>> perforce tree at the moment) and in that process I'm evaluating all 
>> assumptions
>> and test them against a close reading of all relevant RFCs.
>>
>> While reading and applying draft-ietf-tcpm-tcpsecure-09.txt I've come 
>> across a
>> couple of inconsistencies and issues that require further clarification:
>>
>> Section 3.2 Mitigation of Blind RST
>>
>>   [Real world observation]
>>   Some implementations send the RST not on rcv_nxt but on rcv_nxt-1 or
>>   rcv_nxt+rcv_win.  Thus we accept three small windows of rcv_nxt(+-1),
>>   last_ack_sent(+-1) and rcv_nxt+rcv_win(+-1).
>>
>>   Of course the challenge ACK should have the same effect at the expense
>>   of another round trip.  While these three (two in case of rcv_nxt == 
>> last_ack_sent)
>>   do increase the chances of a succesful attack (only every third seq# 
>> has to
>>   be probed plus the average hit rate is increased due to having 
>> two/three
>>   different places that match) real world behavior and interop should be
>>   considered and discussed.
>>
>>   
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev1.316 
>>
>>   
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev1.259 
>>
>>
>>
>> Section 4.2 Mitigation of Blind SYN
>>
>>   [Possible inconsistency in text]
>>   The test in 4.2 eq. 1) is a little different.  In RFC793 it is:
>>
>>    RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
>>
>>   in tcpsecure it is described as one byte larger beyond the real window:
>>
>>    RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND.
>>
>>   This seems to be incorrectly transcribed.
>>
>>
>> Section 5.2 Mitigation of Blind data injection attack
>>
>>   [Clarification]
>>   Data that doesn't satisfy the new check in first paragraph MUST be 
>> discarded
>>   silently. Before RFC793 used to require an ACK to be sent back. This 
>> change
>>   is not sufficiently explained and lacks an obvious rationale.
>>
>>   The second related issue is where this check should be placed 
>> relative to
>>   RFC793 ordering?  Before the fifth check, last sentence (page 72) 
>> "If the ACK
>>   acks something not yet sent (SEG.ACK > SND.NXT) then send an ACK, 
>> drop the
>>   segment, and return." or right after it?  This has implications on 
>> the response
>>   as tcpsecure requires to silently discard the segment.  If it 
>> weren't for the
>>   silent discard the new tcpsecure check could simply replace/extend 
>> the fifth
>>   check from RFC793.
>>
>>
>> Feedback appreciated.
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm