Subject: Re: [tcpm] Congestion control in face of ICMP unreachable messages

From: Daniel Schaffrath <[email-masked]>
Date: Thu, 6 Sep 2007 23:52:26 +0200

On 2007/08/17  , at 18:41, Joe Touch wrote:

> AFAIK, congestion control response to in-band messages (ACKs) and
> timeouts (implied loss, as TCP interprets it), as well as to some new
> fields (ECN, etc.) which are carried in the same packets.
>
> Reactions to external congestion signals - ICMP source quench  
> (which has
> been informally deprecated a while ago, but has not been documented as
> such yet) or otherwise - would constitute another opportunity for a  
> DOS
> attack, and seem like a bad idea to encourage.
I am note sure your security concerns really apply :) If the bad user  
controls the forwarding node, there is no need to rely on ICMP  
message to cause harm. Instead, just dropping random segments would  
do the job. If the bad user is off the forwarding node, she would  
need (as usual) guess port and sequence numbers. If she is able to  
guess right, she might as well opt to send forged ACK dupacks to  
cause harm, or for an ECN capable transport just one ECE marked ACK.

Overall, it seems to me that there don't arise additional attack  
opportunities if there was congestion control on ICMP messages.

But maybe I am missing something?

Thanks again,
Daniel

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

---

From: Daniel Schaffrath <[email-masked]>
Date: Fri, 7 Sep 2007 00:13:51 +0200

On 2007/08/17  , at 18:25, Ted Faber wrote:

> On Fri, Aug 17, 2007 at 06:06:55PM +0200, Daniel Schaffrath wrote:
>> Dear Community,
>>
>> I was wondering if there are any recommendations regarding congestion
>> control in face of ICMP (host/network) unreachable messages. If I am
>> not mistaken there is nothing in the various TCPM documents... nor in
>> any RFC.
>>
>> Maybe you have any pointers?
>
> Sure.  If the code in the destination unreachable message is 2-4 abort
> the connection.  Otherwise, don't.  RFC 1122.
Ok... however, aborting a connection seems somewhat a bit too harsh  
congestion control to me :)

> I wouldn't use ICMP reachability information in congestion control,
> and I don't believe that any standard requires an implementer to do  
> so.
> If packets aren't being delivered, the sending endpoint(s) will slow
> down pretty dramatically, pretty quickly without intervention.  A
> retransmisson timeout puts the endpoint into slow start.
Yes. And that exactly what I am after. Don't you think that this a  
bit to conservative? Especially if you consider exponential back-off.  
I mean, if TCP retransmits after RTO and gets no reply, this  
indicates severe congestion and back-off is fine. But if it gets an  
ICMP unreachable message again, this might allow a less conservative  
behavior?

Another thing is that RTO needs to expire to reach slow-start  
recovery. If my understanding of RFC 1122 is correct, it's still  
standard compliant to continue sending after having received the  
first appropriate ICMP message. Maybe that's a bit too aggressive (as  
opposed to slow-start recovery after an "ICMP induced" RTO).

Thank you,
Daniel

---

From: Ted Faber <[email-masked]>
Date: Thu, 6 Sep 2007 17:43:35 -0700

Acting in no official capacity, I say:

> congestion control to me :)

Assuming you believe these are valid messages, those codes indicate that
the entity you want to talk to is not there or has gone away and isn't
coming back.  The sender is required to terminate the connection because
the network has told it that the receiver cannot be reached and that
further packets will not be delivered.  Sending any packets under those
conditions will just take up space until they're dropped.

> ICMP unreachable message again, this might allow a less conservative  

Huh?

If TCP has gotten to the point where a retransmission timer has gone off
not only has the transmission of the packet to be retransmitted failed,
but enough other packets have been lost that the fast retransmit
algorithm (3 dupacks) has also not happened (yes, the window needs to
have grown to 4...).  In short, there's something very wrong with the
communication between the endpoints, and drastic action is called for.
Specifically, the sender acts as though the connection is almost new -
window is as small as possible and the ssthresh is halved.

Your text above sounds like you're saying that if a sender has heard the
network say that there's a connectivity problem between the sender and
receiver (ICMP destination unreachable) the sender is entitled to react
less conservatively, even though all the evidence is that the link is
congested.

I don't understand that logic at all.  Even if you believe that the ICMP
messages indicate a transient condition and that the connection to the
receiver will eventually be restored, the sender's best information is
that something in the network is confused about how to the destination
(ICMP unreachable) and that the receiver is unable to communicate with
the sender (no ACKs for an RTO).  All evidence is that your packets are
doing no good and possible harm (congesting links over which they're
being wrongly routed).

Explain to me why ICMP messages indicating that your packets are not
being delivered indicate you should not slow down.

> opposed to slow-start recovery after an "ICMP induced" RTO).

I believe your understanding of RFC 1122 is incorrect.  I don't believe
that receiving an ICMP message of any kind has any effect on the TCP
congestion control algorithms whatsoever (other than aborting the
connection in the case above).  ICMP messages are not part of a TCP
connection, and receiving one does not count as receiveing a TCP
packet, much less an ACK.  After all, an ICMP message may well be coming
from an intermediate gateway.

What text have I missed?

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Sep 2007 07:13:12 -0700

Daniel Schaffrath wrote:
>> Reactions to external congestion signals - ICMP source quench (which has
>> such yet) or otherwise - would constitute another opportunity for a DOS
> controls the forwarding node, there is no need to rely on ICMP message
> to cause harm. Instead, just dropping random segments would do the job.
> If the bad user is off the forwarding node, she would need (as usual)
> guess port and sequence numbers. 

Only port numbers. Sequence numbers strictly don't matter for ICMPs.

> If she is able to guess right, she
> might as well opt to send forged ACK dupacks to cause harm, or for an
> ECN capable transport just one ECE marked ACK.

ICMPs don't need to come from the endpoint IP address, i.e., address
verification will prevent spoofed ACKs, but cannot prevent ICMPs, since
the latter need not have spoofed source addresses.

> opportunities if there was congestion control on ICMP messages.

Basically the above; ICMPs don't need to have forged source addresses,
but in-band attacks do.

Joe

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

---

From: Daniel Schaffrath <[email-masked]>
Date: Wed, 12 Sep 2007 20:23:32 +0200

> Acting in no official capacity, I say:
Sorry, I don't get this.

> conditions will just take up space until they're dropped.
I was actually joking about the term "congestion control". To me  
_congestion_ control is about how much to send and not whether to  
send at all. Of course, I understand that the latter is included in  
the former... in some way :)

> less conservatively, even though all the evidence is that the link is
 From my understanding the evidence is that just some link is (was)  
not working and that is not the same as a link is congested. Even,  
there is some slight indication that there is no congestion in the  
network (or at least the very part of it) as the ICMP message (as  
well as the segment eliciting the ICMP message) was not dropped and  
got to the TCP source.

> being delivered indicate you should not slow down.
I am not saying you shouldn't slow down. After RTO of course you  
should reset cwnd and halve ssthresh. I was just thinking of skipping  
(or delaying) doubling RTO if the retransmission after RTO does not  
simply vanish in the network but is  replied to with an ICMP (host/ 
net) unreachable message. This seems reasonable to me if my above  
finding is true.

> from an intermediate gateway.
Maybe my paragraph above was not clear. I am not saying that RFC 1122  
suggests ICMP messages to have effect on cwnd. I am saying that from  
my understanding RFC 1122 allows  a TCP to continue sending segments  
after having received an ICMP host/net unreachable message. This  
seems to me as a waste of bandwidth as the arrival of the ICMP  
message just indicated that right now there is no route to the  
destination. Doesn't that sound reasonable? But maybe continuing  
sending makes sense together with some other RFC I am not aware of  
but someone else on the list.

> What text have I missed?

I don't know. How come you feel you missed some text??

Thanks again!
Daniel Schaffrath

---

From: Daniel Schaffrath <[email-masked]>
Date: Wed, 12 Sep 2007 20:23:27 +0200

On 2007/09/07  , at 16:13, Joe Touch wrote:
>> message
But that is under way, if I am not mistaken (draft-ietf-tcpm-icmp- 
attacks-02). And Linux for instance already implements it...

> the latter need not have spoofed source addresses.
Ok, but if a router is (potentially) able to check for spoofed IP  
source addresses it could as well check for spoofed/illegal ICMP  
payloads (which contain both IP addresses) . Isn't that true?

Apart from that: how common is it to drop spoofed datagrams? It's  
probably a idealistic assumption, isn't it?

[...]

Thank you,
Daniel Schaffrath

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Sep 2007 20:01:18 -0700

Hi, Daniel,

Daniel Schaffrath wrote:
> But that is under way, if I am not mistaken
> (draft-ietf-tcpm-icmp-attacks-02). And Linux for instance already
> implements it...

I've already spoken about this at previous IETFs and on this list. The
basic summary:
- the network is under no obligation to respond with ICMPs within one RTT
- as a result, checking to ensure that ICMPs are in-window is incorrect
as it will drop legitimate responses - or worse, interpret them as attacks

The fact that an I-D remains on this point and that Linux implements it
does not change the above.

> Ok, but if a router is (potentially) able to check for spoofed IP source
> addresses it could as well check for spoofed/illegal ICMP payloads
> (which contain both IP addresses) . Isn't that true?

Routers can check for spoofed addresses as they enter protected regions
of the Internet; if there's a hole in that 'fence' however, packets can
leak in. Once in, they can't necessarily be checked for spoofed
addresses unless they're authenticated, and most are not.

> probably a idealistic assumption, isn't it?

In general, yes. You can't assume that spoofed packets are dropped.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Sep 2007 20:15:30 -0700

>> Acting in no official capacity, I say:

Ted is chair of the working group; he's taking that hat off in this
reply ;-)

...
> _congestion_ control is about how much to send and not whether to send
> at all. Of course, I understand that the latter is included in the
> former... in some way :)

Congestion is "packets that slows down or drops other packets".

Packets sent to unavailable ports may have nothing to do with congestion
- they don't have to compete for resources. It's not about relieving the
network from congestion - congestion control handles that.

A good example: UDP has no congestion control, but can generate ICMP
responses.

...
> From my understanding the evidence is that just some link is (was) not
> working and that is not the same as a link is congested. Even, there is
> some slight indication that there is no congestion in the network (or at
> least the very part of it) as the ICMP message (as well as the segment
> eliciting the ICMP message) was not dropped and got to the TCP source.

The ICMP travels on the reverse path; there could be congestion in the
forward path.

...
> I am not saying you shouldn't slow down. After RTO of course you should
> reset cwnd and halve ssthresh. I was just thinking of skipping (or
> delaying) doubling RTO if the retransmission after RTO does not simply
> vanish in the network but is  replied to with an ICMP (host/net)
> unreachable message. This seems reasonable to me if my above finding is
> true.

Host/net unreachable means that you sent some packets along a path that
couldn't reach that host/net. That's not to say that other packets
wouldn't be delivered properly.

It's like hitting a roadblock on the way across town. It doesn't say the
endpoint is dead; that's why you don't give up, and also why you need
not change your congestion parameters. Finding a bad path could happen
by a routing transient - if you get these replies over a RTT, then maybe
you give up. Or two RTTs. That's why 1122 doesn't say to ignore these -
it says to use them as a hint. They're a hint that something can't be
reached - not that there's congestion.

...
> suggests ICMP messages to have effect on cwnd. I am saying that from my
> understanding RFC 1122 allows  a TCP to continue sending segments after
> having received an ICMP host/net unreachable message. 

Correct.

> This seems to me
> as a waste of bandwidth as the arrival of the ICMP message just
> indicated that right now there is no route to the destination. Doesn't
> that sound reasonable? But maybe continuing sending makes sense together
> with some other RFC I am not aware of but someone else on the list.

It's consistent within 1122. The message doesn't say there's congestion;
it says routing doesn't work for the packet you sent. It may be a waste
of bandwidth, but that's not the same as congestion - if you're actually
competing for resources others need, your data packet would have been
dropped and you wouldn't get an ICMP at all. Getting the ICMP
effectively says you are NOT experiencing congestion.

Joe

---

From: Daniel Schaffrath <[email-masked]>
Date: Fri, 14 Sep 2007 02:01:00 +0200

Thanks, Joe, for all the patience.

On 2007/09/13  , at 05:01, Joe Touch wrote:

>>>>> (which
>>>>> has
> I've already spoken about this at previous IETFs and on this list.
Sorry. I am actually new to the matter...

> The basic summary:
That's a very valuable hint! And gives motivation why RFC 1122 after  
the receipt of an ICMP (host/net) unreachable message only requests  
to flag a "soft error" to the application allows continuing sending  
(simply because the issue about the unreachability might have changed  
in the meantime...) Correct?

Are there any other boundaries as RTT for ICMPs? Anyway, how come  
that there is the possibility of late ICMPs?

> does not change the above.
And how come that there is an I-D on dropping legitimate responses  
from the network?

Maybe one mitigation might be to relax the window check to accept a  
few older windows and not just the current one, thereby allowing  
proper handling of "late" ICMPs, but still filtering some malicious  
ICMPs . But as this is so obvious is has probably some (hidden)  
shortcoming (which I can't think of at the moment).

>> source
But, again: isn't it true that if and only if for a given datagram a  
router is able to decide whether the source address of that datagram  
is spoofed, then that router could also decide (if that datagram  
contained an ICMP unreachable message) whether the source IP in the  
ICMP payload is spoofed or not (and act accordingly, i.e., drop it or  
not). So, overall there don't arise additional attack opportunities  
when there was some (to be defined) congestion control in face of  
ICMP (host/net) unreachable messages (which was my original claim).  
Sorry, maybe I am bit theoretical here, but I'd love to check if my  
understanding is correct.

[...]

Thanks again and thanks a lot!!
Daniel Schaffrath

---

From: Daniel Schaffrath <[email-masked]>
Date: Fri, 14 Sep 2007 02:01:22 +0200

> Ted is chair of the working group; he's taking that hat off in this
I see. I still don't get why he feels there is some need to reply  
"unofficially". Because of "Huh?"..?

>> send
>> not
There could be congestion only in that part of the path which the  
datagram eliciting the ICMP message has not yet travelled through,  
though. Up to that node where the ICMP message is generated there as  
no congestion as the eliciting datagram was not dropped.

>> should
You mean other packet to be packets to another destination? Not other  
packet to the same destination (but from a different connection)?

> reached - not that there's congestion.
Yes. That is exactly my understanding. But as you (kindly) explain to  
me exactly my understanding I am really desperate what from my above  
writing could make you think that I have a different understanding. I  
am just talking about what to do if after a RTO exceeded the  
retransmission is replied to with an ICMP (host/net) unreachable  
message instead of no reply at all (indicating true congestion). (As  
I feel we have agreed upon) RFCs say to back-off exponentially in  
that case. Whereas I feel skipping further back-off might be non- 
contraproductive  (BUT performance enhancing as it allow faster  
recovery!) as there is no evidence of congestion in the network (at  
least not for the very part of the path which is involved of the  
delivery of the ICMP unreachable message... if there is congestion in  
the rest of the path, it would be immediately discovered after the  
faster recovery).

> It's consistent within 1122. The message doesn't say there's  
Yes!

> dropped and you wouldn't get an ICMP at all.
I really don't get this. With the same argument I could justify that  
a hacked/modified TCP (which for instance increases cwnd by two  
(instead of one) MSS for each ACK in slow-start) is just fine...

Really, you don't want waste of bandwidth, do you? Of course,  
considering the hint you gave in the other email about late ICMP,  
it's no necessarily a waste, as in case of late ICMPs the issue might  
already have been resolved in the meantime.

> Getting the ICMP

Thank you once again,
Daniel

---

From: Ted Faber <[email-masked]>
Date: Thu, 13 Sep 2007 17:53:15 -0700

> >Acting in no official capacity, I say:

I'm one of the co-chairs of the TCPM working group.  I'm just having a
public conversation with you and neither you nor observers of this public
conversation should take it as being an official position of this august
WG.

Because tempers fray and IETF participants are somewhat averse to people
throwing their weight around, those of us who don't want to have those
kinds of arguments try to be specific about when we're speaking ex
cathedra. :-)

> well as the segment eliciting the ICMP message) was not dropped and  

So, the TCP stack really just knows that packets are not being
acknowledged, and the current design interprets that as congestion.
That's a conservative approach, and one people can and do argue about.
If you'd like to argue about that interpretation of loss, the end-to-end
mailing list might be a better place to do so.  I mean we'll talk about
it, too, but I think of it as a bigger picture issue.

Still and all, one could say that the ICMPs count as extra evidence that
a connection isn't congested but confused and should be treated
differently.  I'd recommend against treating them this way because:

	* ICMP operates on a different timescale than TCP.  It may take
	  a router longer to decide that there's a host unreachable
	  situation than the TCP stack would.  It may also take a router
	  longer to detect the opposite.
	* They're really easy to spoof.

I don't think you gain very much, either.  If your application believes
that the connection has stuttered - a route flap or something - the
easiest way to fix it may be to reconnect.  I'll bet you do this a
couple times a day with your browser.  Hitting reload on a slow loading
page does exactly this.  Other applications may value continuity of
connection more.

I think that kind of semantics - whether it's better for my application
to retry or to stick it out on a slow connection - is known by the app
and shouldn't be encoded in the transport.  I realize that not going
into exponential backoff is a pretty small case of a change in
semantics, but it complicates things and it's not intuitive to me that
it's worth the cost.

> net) unreachable message. This seems reasonable to me if my above  

I think its extra complexity for minimal gain.

But, I haven't done anything to validate that opinion.  Do you have some
evidence either way?

> but someone else on the list.

I think I was unclear.  There are several kinds of destination
unreachable ICMP messages - subtypes of the message.  RFCs 792 and 1122
list them.  There are a set of them that indicate that any transport,
including TCP, that get one have to shutdown the connection.  If a host
gets a destination unreachable message of the subtype "protocol
unreachable" the host MUST abort the connection that caused it.  That
message indicates a long term error.  If the destination unreachable
message indicates an error that may not be so long term, the connection
should continue to transmit, and if the transport decides to terminate
the connection (e.g. a TCP timeout) it should report the ICMP error as
well.

That second choice is there because the subtypes in question could be
caused by a single misrouted packet or something and are not strong
evidence that the connection is impossible.

Make sense?

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Sep 2007 23:30:14 -0700

Daniel Schaffrath wrote:
...
> That's a very valuable hint! And gives motivation why RFC 1122 after the
> receipt of an ICMP (host/net) unreachable message only requests to flag
> a "soft error" to the application allows continuing sending (simply
> because the issue about the unreachability might have changed in the
> meantime...) Correct?

Basically. It's an indication that a packet hit a roadblock, but not
that the roadblock is essentially permanent. That happens only at the
destination (i.e., if the destination is gone, then game's over).

> Are there any other boundaries as RTT for ICMPs? 

None per se.

> Anyway, how come that
> there is the possibility of late ICMPs?

Routers respond with ICMPs only when they have cycles - otherwise, they
could go into overload giving feedback. That's in RFC1812.

> And how come that there is an I-D on dropping legitimate responses from
> the network?
> 
> Maybe one mitigation might be to relax the window check to accept a few
> older windows and not just the current one, thereby allowing proper
> handling of "late" ICMPs, but still filtering some malicious ICMPs . But
> as this is so obvious is has probably some (hidden) shortcoming (which I
> can't think of at the moment).

Once the window wraps all windows look the same. At that point, there's
nothing useful to check.

> router is able to decide whether the source address of that datagram is
> spoofed, then that router could also decide (if that datagram contained
> an ICMP unreachable message) whether the source IP in the ICMP payload
> is spoofed or not (and act accordingly, i.e., drop it or not).

Not true. IP addresses are checked two ways - with explicit
authentication (which we're not talking about; that involves IPsec,
e.g.) or by verifying which port they arrive on (and which router they
arrive from). Let's focus on that second part.

Let's say that IP address X must come in on port 3 from router Q. ICMPs
that report IP address X incorrect can come in on any port, from any
router. There's no rule that ICMPs must be routed the same way as the IP
packets they report on. The ICMP has a different source IP address, so
it could easily be routed via other paths.

> So,
> overall there don't arise additional attack opportunities when there was
> some (to be defined) congestion control in face of ICMP (host/net)
> unreachable messages (which was my original claim).

I think there do, because of the above...

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Sep 2007 23:44:29 -0700

Hi, Daniel, et al.,

Daniel Schaffrath wrote:
> though.

Correct, but that's not relevant. Getting an ICMP message tells you a
single packet got to a certain point in the path; it doesn't say that
other packets didn't get dropped. It's not an indication of "no
congestion", as a result.

> Up to that node where the ICMP message is generated there as no
> congestion as the eliciting datagram was not dropped.

"No congestion" for that packet. Unless you get an ICMP for every packet
you sent, you can't assume that you have no congestion. However, since
routers are supposed to not send ICMPs that frequently (see RFC1812),
only a fraction of packets that arrive at a router would generate an
ICMP reply (even if all 'should').

...
> packet to the same destination (but from a different connection)?

Packets to the same destination from the same connection could go on a
different path and be delivered properly. The Internet makes no
guarantee that all packets travel the same path all the time, even
within a single flow.

> Yes. That is exactly my understanding. But as you (kindly) explain to me
> exactly my understanding I am really desperate what from my above
> writing could make you think that I have a different understanding. I am
> just talking about what to do if after a RTO exceeded the retransmission
> is replied to with an ICMP (host/net) unreachable message instead of no
> reply at all (indicating true congestion).

An ICMP host/net unreachable doesn't indicate "no congestion", so
there's no reason to act differently when you get an individual such
message. If you get repeated such messages, the network is saying that
it can't find a way around a roadblock - presuming, however, that the
connection isn't making any progress. If it is, all you know is that
some of the multiple paths are broken. None of this has anything to do
with congstion, though.

> (As I feel we have agreed
> upon) RFCs say to back-off exponentially in that case.

For true congestion.

> Whereas I feel
> skipping further back-off might be non-contraproductive  (BUT
> performance enhancing as it allow faster recovery!) as there is no
> evidence of congestion in the network (at least not for the very part of
> the path which is involved of the delivery of the ICMP unreachable
> message... if there is congestion in the rest of the path, it would be
> immediately discovered after the faster recovery).

See above.

>> It's consistent within 1122. The message doesn't say there's congestion;

It doesn't say there's no congestion either. It doesn't need to say one
or the other!

> I really don't get this. With the same argument I could justify that a
> hacked/modified TCP (which for instance increases cwnd by two (instead
> of one) MSS for each ACK in slow-start) is just fine...

That's violating other principles of TCP. Why is that justified because
of this?

> Really, you don't want waste of bandwidth, do you?

The Internet wastes bandwidth all the time. TCP probes waste bandwidth,
e.g. What we want to reduce is bandwidth that is wasted that could be
used for other connections - that's congestion. Sending packets when
there *might* be a roadblock (which is what a single ICMP host/net
unreachable means) isn't wasteful; it's needed for discovery of
alternate paths.

Joe

---

From: Daniel Schaffrath <[email-masked]>
Date: Thu, 20 Sep 2007 21:21:14 +0200

[...]
> it, too, but I think of it as a bigger picture issue.
I am subscribed to it. My impression is that the (active) audience is  
quite is same as on this list... and they all are "holistics" ;)

> 	  longer to detect the opposite.
In my (naive?) understanding they not necessarily operate on a  
different timescale. For instance, it may take a router some time to  
execute an ARP request which may fail and then it would send a late  
ICMP (for the initial early segment, the later one got queued, then  
dropped). But if for whatever reason a port is disconnected (and by  
this a whole (sub-)net vanishes from the routing table) the router  
might be able to immediately (within an RTT) decide to send an ICMP.  
In either case the TCP source can decide about the timescale an  
arriving ICMP operates on (by looking at the sequence numbers  
therein). Of course, provided all involved nodes being non-malicious.

> 	* They're really easy to spoof.
I got that in the meantime from Jon explanation. And how come, if  
they are really that easy to spoof, that for ICMP port/proto/etc.  
unreachable messages RFC 1122 asks to drop the connection? Isn't that  
a very easy attack then. btw: I just noticed while browsing the Linux  
source that Linux treats port/proto/net/host unreachable messages all  
the same, i.e., flag an error on the socket and that's it.

Anyways: if ICMP were used to skip doubling RTO an attacker cannot  
make a TCP source to flood the network by this.

> page does exactly this.  Other applications may value continuity of
I exhibit exactly this behavior. And I don't like it. I'd like the  
network to solve these issues for me... :)

[...]

> But, I haven't done anything to validate that opinion.  Do you have  

Complexity seems to be almost a dysphemism to me here. The gain is  
obviously a much faster restarting connection. And it's  
extraordinary... given an adequate scenario which is of course not  
the usual dial-up leafnode to the wired Internet but for instance a  
node which is part of a subnet managed by olsrd (causing route  
interruptions and the like).

The question is if there is some rationale for this behavior.  
Actually, I was thinking there was (ICMP reply for single slow-start  
recovery retransmit indicating no congestion for the first few hops  
at least). But in the meantime I found that for zero window probing  
(which is comparable to "roadblock" probing) RFC 1122 in 4.2.2.17  
recommends  exponentiell back-off as well. Whereas I understand  that  
exponentiell back-off is necessary for the _network_ to recover from  
severe congestion, I don't understand why exponentiell back-off is  
recommended for recovering from zero windows (which is more or less  
_application_ congestion). Of course, for zero window probes which  
are not ACKed back-off is essentiel. There is a DISCUSSION paragraph  
in 4.2.2.17 which is unfortunately not clear to me. It might be  
understood as if exponentiell back-off allows fast recovery from a  
zero window condition, although (from my understanding) it does  
exactly the opposite. Of course, it may all boil down to defining  
words, i.e., exponentiell back-off being fast by definition as  
complexity theory knows off much worse growth. But "traditionally"  
exponentiell is not fast.

Maybe you have further pointers?

Thank you,
Daniel Schaffrath

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Sep 2007 15:38:18 -0700

Daniel Schaffrath wrote:
...
> In my (naive?) understanding they not necessarily operate on a different
> timescale. For instance, it may take a router some time to execute an
> ARP request which may fail and then it would send a late ICMP (for the
> initial early segment, the later one got queued, then dropped). But if
> for whatever reason a port is disconnected (and by this a whole
> (sub-)net vanishes from the routing table) the router might be able to
> immediately (within an RTT) decide to send an ICMP. In either case the
> TCP source can decide about the timescale an arriving ICMP operates on
> (by looking at the sequence numbers therein). 

If the sequence numbers wrap, it can't tell much. Nothing guarantees
that ICMPs are generated before such wrap occurs - even assuming benign
behavior.

...
> network to solve these issues for me... :)

A "best effort" network doesn't provide that service. You may want a
circuit-oriented system.

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 24 Sep 2007 14:36:27 -0700

> therein). Of course, provided all involved nodes being non-malicious.

Yeah, but that seems like a long run for a short slide to me, as a
private individual.  It might help in very simple cases, but there are a
couple "might"s in there and a TCP endpoint making a decision about an
ICMP packet based on matching sequence numbers.  Practically this seems
to be making TCP more brittle to deal with a pretty uncommon case.

> the same, i.e., flag an error on the socket and that's it.

Have you seen:

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tcpm-icmp-attacks-02.txt

Fernando and this group are looking at these issues.  Perhaps your ideas
can be combined with that document?

> make a TCP source to flood the network by this.

I don't think any of that is an obvious mechanism to cause a DoS attack.

> network to solve these issues for me... :)

I do it, too.  TCP serves a lot of applications that aren't people
browsing the web.

Why do you think TCP should handle this rather than Firefox (for
example)?

> Complexity seems to be almost a dysphemism to me here.

Perhaps you think complexity is a dirtier word than I do.  It's hard
to understand how making TCP's retransmission depend partially on ICMP
isn't making TCP more complex.  I'm happy to use whatever term you
prefer.

>                                                        The gain is  

It seems like the case you're considering - a TCP connection that has a
conncectivity breach that's noticed by ICMP and restored within a few
RTTs - is pretty uncommon.  Many application protocols (HTTP,FTP) are
already prepared to deal with these kind of interruptions.  Again, I
don't see a compelling case for the benefits.  Just speaking for myself.

> exponentiell is not fast.

4.2.2.17 is dealing with the case that one end of the connection is
advertising a 0 size window.  In this case the other end knows that the
connection still exists, but it isn't accepting data.  That whole
probing operation is to elicit a window update if one has been lost.

In general, TCP is conservative with sending probes of any kind.