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

From: Andre Oppermann <[email-masked]>
Date: Mon, 02 Jun 2008 00:17:41 +0200

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.

-- 
Andre

[email-masked]

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jun 2008 17:41:05 -0700

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.

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

	- if source IP addresses are not known, the mitigations are not
	needed

	- the mitigations may increase the time needed to respond to
	a legitimate RST, incurring extra RTTs or retransmissions
	vs. an unmodified system

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

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

It seems like these ought to be added, in light of the note below.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 2 Jun 2008 19:45:15 -0700

Andre,
    Pl see comments inline.  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Andre Oppermann
> Sent: Sunday, June 01, 2008 3:18 PM
> To: [email-masked]
> Subject: [tcpm] Q&C regarding tcpsecure-09 recommendations
> 
> 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.

Cool, thanks.

> 
> While reading and applying draft-ietf-tcpm-tcpsecure-09.txt 
> I've come across a couple of inconsistencies and issues that 
> require further clarification:
> 

After you sent the challenge ACK, are you saying that implementations
can still respond with the above values ? (rcvnxt -1 ) rcvnxt + rcvwin
(+-1) etc., ? OR are you saying that the seq# of RST with rcvnxt - 1
should be accepted [Some implementations do this to accept the RST of
the keepalive packet]

FWIW, section 8 (middlebox considerations talks about some corner cases)

Also the following table summarises (standard way) way to generate RST
's :

 * Generating a RST packet in response to an incoming packet.
 * According to TCP/IP Illustrated, Vol 2, page 994:
 *
 * +--------------+----------------------------------------------------+
 * |              |                 RST segment generated              |
 * |              +----------------+-----------------+-----------------|
 * | rcvd segment |      seq#      |      ack.field  |       flags     |
 * |===================================================================|
 * | Contains ACK | rcvd ack.field |          0      |      TH_RST     |
 * |--------------|----------------+-----------------+-----------------|
 * | ACK-less     |         0      | rcvd seq# + len | TH_RST | TH_ACK |
 * +--------------|----------------+-----------------+-----------------+
 *
 * The ACK flag should be set in all segments except when an initial SYN
 * is sent. So all RST packet will have 0 for ack number, without the
ACK
 * flag, except when the RST is in response to an SYN packet.
 */

>   This seems to be incorrectly transcribed.

Good catch, I'll change it. I thought I had removed it before.

[I think I know the reason why this = got added, this is one of the
corner cases which we have fixed it long back, I'll see if I can
remember that and post it later, in any case I don't want to fix that in
this draft.]

>   is not sufficiently explained and lacks an obvious rationale.

Good question, 793 implicitly tells that the following ACK range is
acceptable :
In other words an ACK value is acceptable if it is ((SND.UNA-(2^31-1))
<= SEG.ACK <= SND.NXT). 

Anything > SND.NXT above would solicit an ACK to be sent back, this is
simply an ACK being sent for something that has not yet been actually
sent. 

With this mitigation we are saying that the acceptability range becomes
:

((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT).

Since we haven't accepted this segment we drop this silently to
distinguish with the above case. This is whole point. (old ACK versus an
ACK ack'ing data that is unsent)

FWIW, this is been implemented and tested in some of the stacks and I
don't recall seeing any issues here.

I agree that generating an ACK back is also fine and shouldn't pose any
issues. 

I will think about this a bit more and will get back since my opinion is
either way is fine.

>   segment, and return." or right after it?  This has 

Should be before that, this is what we have tested with. Although I
can't think of on top of my head what would happen if we put after
that... 

> implications on the response

Agreed. I think it is just a matter of perference and I think both
choices don't have any implications that I can see. 

> Feedback appreciated.

Thanks,
-Anantha

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 2 Jun 2008 20:08:07 -0700

> Behalf Of Joe Touch
> Sent: Monday, June 02, 2008 5:41 PM
> To: [email-masked]
> Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations
> 
> Hi, all,

Others can comment, but wanted to offer my perspective as one of the
document's authors. Pl find inline responses..

> 
> This is, IMO, a signal to review the recommendations in 
> Section 1.1. I was always concerned that these mitigations 

tcpsecure-09 has been reviewed and that includes the AS. There have been
some general comments received which will be incorporated in the next
revision.

> would be misinterpreted as applying to hosts in general, 
> which they do not.

Actually this is TCP document and hence these mitigations apply to any
system that thinks it needs those. Also the definition between hosts and
routers have diminished long ago. The AS is in place for the very reason
you wanted it to be, i.e, these mitigations are generally useful for
long lived sessions (SHOULD) than short lived (MAY) sessions. A TCP
stack which caters to multitude of applications (short and long lived)
may want to take the super set approach, IMO. It is purely an
implementation decision.

> 	even presuming source IP addresses are known

Source port randomization is one way of adding robustness and does not
every situation. Also you can't assume everyone is doing src port
randomization. Even then having these mitigations would make the attacks
described in the document harder to accomplish.

> 	- if source IP addresses are not known, the mitigations are not

I think this is very obvious in the document. Right from the intro which
talks about the attack vectors, and what is needed to accomplish the
attack. 

> 	a legitimate RST, incurring extra RTTs or retransmissions

Yes, this is obvious too due to the challenge ACK being sent.

> 	considerations, but it's buried w.r.t. applicability)

Oh, the way I read the draft the above fact is mentioned all over the
draft.. I can point out all the places if you want, but we have been
thru this before and I have incorporated the feedback received from you
but I am surprised that you are bringing this one up now.

> 	applicability, and worth adding the ISP example, IMO)

Well, I would think that we generally don't want to repeat the same text
all over the document again and again, but if the work group believes in
this redundancy as you semm to do, I am more than willing to add it. 

-Anantha
> 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.
> > 
> I've come 
> > across a couple of inconsistencies and issues that require 
> further clarification:
> >

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jun 2008 20:18:13 -0700

Anantha Ramaiah (ananth) wrote:
...
> randomization. 

No, you cannot. The responsibility for protecting the session then falls 
to the side that initiates it (fair territory, IMO), rather than the 
side that receives the RST (which is arbitrary).

> Even then having these mitigations would make the attacks

Agreed that it makes the attacks still harder, but if they're already 
hard enough, then the mitigations aren't needed.

> but I am surprised that you are bringing this one up now.

I noted below why I am raising it now (the FreeBSD note).

> this redundancy as you semm to do, I am more than willing to add it. 

I don't think it's huge; it is just a summary of - as you note - 
information noted elsewhere.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Wed, 4 Jun 2008 12:58:02 -0400

Hi,

On 2008-6-2, at 20:41, ext Joe Touch wrote:
> 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.

do you think that a short paragraph in Section 1.1 that discusses the  
downsides of implementing the checks where not needed would be helpful?

Currently the document says "The mitigations suggested in this draft  
SHOULD be implemented in devices where the TCP connections are most  
vulnerable to the attacks described in this document. (...) These  
mitigations MAY be implemented in other cases." I think you're saying  
that the last sentence may not be detailed enough to allow  
implementors to judge the tradeoffs?

Lars
(as an individual)

---

From: Andre Oppermann <[email-masked]>
Date: Wed, 04 Jun 2008 22:43:49 +0200

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

>     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

For almost all examples above both endpoint plus at least one port
number are known.

>     a legitimate RST, incurring extra RTTs or retransmissions

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.

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

>     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

> ------------------------------------------------------------------------
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Jun 2008 13:50:07 -0700

> downsides of implementing the checks where not needed would be helpful?

Yes.

> that the last sentence may not be detailed enough to allow implementors 
> to judge the tradeoffs?

Yes, that's partly it. The key is that there are two issues that don't 
come out just because they're ref'd off to the document (i.e., 
"described in this document" isn't sufficient; it's important to 
summarize these):

	1. these mitigations help only a very small class of situations
	that may be typical for unprotected routers, but are currently
	very rare otherwise.

	2. of particular recent note, these mitigations are not useful
	to on-path attacks, such as ISP-issued RSTs

	2. adding these mitigations complicates the TCP implementation,
	and makes it less robust to legitimate RSTs, esp. in the
	presence of reordering; it can increase the time needed to
	reset a connection by one or more RTTs

Joe

---

From: Andre Oppermann <[email-masked]>
Date: Wed, 04 Jun 2008 23:13:36 +0200

>     Pl see comments inline.  

Likewise.

> should be accepted [Some implementations do this to accept the RST of

This +-1 extension is done to accept the initial RST w/o having to send
a challenge ACK.  It has been observed by my fellow FreeBSD developer
Qing Li that certain system send the RST to weird off-by-one places in
either direction.

A surprisingly large number of RSTs are generated by socket closes of
connections that actually were in use shortly before.  Depending on the
exact timing of the connection teardown the RST is not sent in response
to some incoming segment but from the tcpcb state to inform the other
end of the immediate termination of this connection.

>  * According to TCP/IP Illustrated, Vol 2, page 994:

Would be great to hear about the corner case.

> simply an ACK being sent for something that has not yet been actually

I can only partly follow you here.  My interpretation of the text in RFC793
tells us to send back a challenge-ACK to re-synchronize the connection.
Not to ACK something not yet sent.

> I will think about this a bit more and will get back since my opinion is

I don't doubt the extended check at all.  I'm only concerned about its
relationship to the ACK check in RFC793 (section 3.9, page 72, fifth check,
ESTABLISHED STATE, first paragraph, last sentence) in two ways:

  a) tcp-secure section 5.2 essentially makes this check just tighter with
     the addition of the lower bound of (SND.UNA - MAX.SND.WND).  Instead
     of being another check (with a as of yet unclear ordering relative
     to RFC793) this one could simply replace the one from RFC793.  Would
     make the text and application of the check more clear.

  b) the change from a challenge-ACK (as my interpretation of RFC793) into
     a silent drop.

> can't think of on top of my head what would happen if we put after

Then it should only test for the lower bound, not the upper one.
Otherwise the check from RFC793 would never trigger again.  Everything
is already filtered.

  5a) (SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT  [tcp-secure 5.2]

  5b) SEG.ACK <= SND.NXT  [RFC793, expression changed from negative to positive]

> choices don't have any implications that I can see.

My vote goes to replacing the fifth check of RFC793.  Whether to silently
ignore or sending a challenge-ACK I'm still undecided.

-- 
Andre

[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Jun 2008 14:50:14 -0700

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

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

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

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

> For almost all examples above both endpoint plus at least one port

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.

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

> layer. 

There's nothing wrong with that; that's its intent.

> TCP-MD5 can do better by doing all incoming segment checks

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.

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

> 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

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Jun 2008 14:58:34 -0700

Andre Oppermann wrote:
...
> Agreed for the second part about the potential for the time increase.
> Not agreed to the first part.  All kinds of mitigations make TCP
> implementations more complex.  Port randomization does, TCP-MD5 does,
> IPsec does and so on.  You can trust me on this one. ;-)

IPsec has nothing to do with the TCP implementation; it may make the 
stack more complex, but not TCP. Port randomization is a one-time event 
during SYN creation, and should be easy to factor out as a separate 
call. TCP MD5 is complex, but already implemented.

The complexity I'm referring to is reflected in the exchange on details 
and corner cases you've posted to this list.

> Repeating myself:
> 
> The extra time it may take in an edge case is not terribly high.  Most
> RSTs will match and do their thing. 

Actually, you've already indicated cases where that might not be true; 
if RSTs are used to shut down typical connections "just in case", if any 
of the in-transit data was lost, then these will trigger the ACK 
exchange and extra RTT. This costs extra time, extra packets, and extra 
processing on both ends - all for a NON MALICIOUS CASE.

 > As far as my understanding

Correct; however, just because an endpoint didn't expect a packet does 
not imply it is an attack either. That's the flaw in this system, IMO - 
and a reason why bursts of RSTs or SYNs to the same addr/port pair are a 
fairly clear indication of a problem, the filtering out of which would 
make these mods completely unnecessary.

Joe

---

From: Andre Oppermann <[email-masked]>
Date: Thu, 05 Jun 2008 00:54:47 +0200

Joe Touch wrote:
>>> I was always concerned that these mitigations would be misinterpreted 
>>> as applying to hosts in general, which they do not.
>>

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

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

> (incorrectly) inferring that RSTs in-window but not at the edge are 

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?

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

> Data issues should be, IMO, solved by the use of true security, e.g., 

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.

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

> sufficient signal that something is amiss.

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

> satellite Internet connections, or over some data modems.

What is lost with a delayed RST vs. a prematurely aborted connection?

> SPI. Tossing packets with invalid SPIs doesn't cost as much as full 

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.

> replacement is to check the packet's authenticity before doing any TCP 

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?

---

From: Andre Oppermann <[email-masked]>
Date: Thu, 05 Jun 2008 01:01:46 +0200

> call. TCP MD5 is complex, but already implemented.

Port randomization is complex to implement.

> and corner cases you've posted to this list.

There are just as many corner cases with (true) port randomization.
Have a look at its CVS history in the BSDs.  Or Linux.  Took a couple
iterations.

> processing on both ends - all for a NON MALICIOUS CASE.

Normally the connection is in an idle state.  It is primarily observed
with web servers where either the client or server wants to do persistent
connections and the other end does not.  Or it times out.  There would be
no extra round-trip for the RST to be come effective.

> make these mods completely unnecessary.

I'm all ears on your magic RST/SYN burst filter.

-- 
Andre

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Jun 2008 16:45:18 -0700

Hi, Andre,

Andre Oppermann wrote:
...
> 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.

> AFAIK nobody has proposed such a RST detector in any I-D yet.  That

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

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

> the stream and have it processed but TLS will get out of sync and

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

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

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

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

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

Done.

>> RTTs these days can be upwards of a second or more, esp. when 
>> involving satellite Internet connections, or over some data modems.
> 

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.

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

SPIs are 32 bits.

>> 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 equivalent is source port randomization.

> 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

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Jun 2008 16:48:53 -0700

Andre Oppermann wrote:
>> stack more complex, but not TCP. Port randomization is a one-time 
>> event during SYN creation, and should be easy to factor out as a 
>> separate call. TCP MD5 is complex, but already implemented.
> 

It's already implemented. See my other reply.

>> The complexity I'm referring to is reflected in the exchange on 
>> details and corner cases you've posted to this list.
> 

Multiple iterations is not an indication of difficult corner cases.

>> if RSTs are used to shut down typical connections "just in case", if 
>> any of the in-transit data was lost, then these will trigger the ACK 
>> exchange and extra RTT. This costs extra time, extra packets, and 
>> extra processing on both ends - all for a NON MALICIOUS CASE.
> 

It's also been observed in web servers that want to reduce the amount of 
TIME_WAIT state they hold - and thus kernel memory they tie up - for 
connections that clients close by normal means.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 9 Jun 2008 23:32:45 -0700

Andre,
   Sorry about the late response, I had marked it for later response and
got to it just now. 

<snip>
   
> 
> This +-1 extension is done to accept the initial RST w/o 
> having to send a challenge ACK.  It has been observed by my 
> fellow FreeBSD developer Qing Li that certain system send the 
> RST to weird off-by-one places in either direction.
> 
> A surprisingly large number of RSTs are generated by socket 
> closes of connections that actually were in use shortly 
> before.  Depending on the exact timing of the connection 
> teardown the RST is not sent in response to some incoming 
> segment but from the tcpcb state to inform the other end of 
> the immediate termination of this connection.

Ok, but do you see the need to mention this +-1 case in the draft, since
the mitigation is the same from all the cases. Whether or not to send
the challenge ACK for the cases you mention should be treated as an
optimization and should be left to implementers choice, IMO.

<snip>

> remember that and post it later, in any case I don't want to fix that 
> in this draft.]
> 

I'll mention this in a separate email, I need to dig up my notes since
on top of my head I am unable to construct it.

<snip>

> 
> I can only partly follow you here.  My interpretation of the 
> text in RFC793 tells us to send back a challenge-ACK to 
> re-synchronize the connection.

Correct, I should have been clear : 793 tells : if you receive an ACK
for unsent data send a corrective ACK to re-sync the connection. 

<snip>

> 
> I don't doubt the extended check at all.  I'm only concerned 
> about its relationship to the ACK check in RFC793 (section 
> 3.9, page 72, fifth check, ESTABLISHED STATE, first 
> paragraph, last sentence) in two ways:
> 

Actually I did a deeper look into the implementation what we have and we
are infact (for the same reasons) which you mention above dropping the
segment and sending the corrective ACK. 

> >>   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
> Otherwise the check from RFC793 would never trigger again.  
> Everything is already filtered.

Correct. Something like this :

if (TCP_SEQ_RANGE (TCB.SNDUNA, SEG.ACK, TCB.SNDNXT) {
    // new acknowledgement, do the necessary action
} else {
    if TCP_SEQ_RANGE ((TCB.SNDUNA - max_window), SEG.ACK, TCB.SNDUNA) {
         do nothing; /* accept it */
    } else {
        discard the segment;
        send corrective ACK;  // this step is the same as what RFC is
saying today. 
    }
}

Where max_window is hardcoded to some value [ taking into account window
scaling as well]

....
....
process the segment text.

> 
> My vote goes to replacing the fifth check of RFC793.  Whether 
> to silently ignore or sending a challenge-ACK I'm still undecided.

Sure, like I said our implementation already does what you are
mentioning. We do send the corrective ACK for tcp-secure case as well.
So I have no problems mentioning that in the document. I can add this in
the document. 

Good comments, thanks!

-Anantha