Subject: [tcpm] Some comments on tcpsecure

From: Fernando Gont <[email-masked]>
Date: Fri, 04 Apr 2008 15:30:24 -0300

Folks,

I have not yet reviewed the entire document (but will do). However, 
reading the security considerations section (and at the risk of 
sounding our own horn?), I see this document does not reference two 
closely related wg documents of the tcpm and tsvwg working groups.

The first one is the ICMP attacks draft 
(draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the security 
implications of ICMP on TCP conenctions, it does not reference the 
I-D. IIRC, this had already been pointed out by Joe (?). As far as 
the specifications are concerned, you shouldn't bother to fix 
TCP-based reset attacks if you don't fix the the ICMP-based ones.

The other doc is the port randomization draft 
(draft-tsvwg-port-randomization). All the math in the "Slipping in 
the window" paper assumes TCP implementtions use a small port number 
subspace for selecting the ephemeral ports. And also assumes that 
implementations use a trivially-predictable sequence. Clearly, port 
randomization is a trivial mitigation for both these and all other 
off-path attacks that require the attacker to guess or know the 
four-tuple that identifies the connection to be attacked.

Thanks,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 04 Apr 2008 12:55:00 -0700

> TCP-based reset attacks if you don't fix the the ICMP-based ones.

Agreed; should this doc recommend filtering out ICMPs as a result? 
(there's no in-window checks that are meaningful, since ICMPs are not 
guaranteed to be timely) I.e., something stronger than "there's nothing 
we can do", which is what is implied in the current security considerations.

> (draft-tsvwg-port-randomization). 

Also ISN randomization (RFC-1948), for similar reasons. Even though some 
of the RST attacks span the entire window, knowing the ISN can help 
during the initial handshake and shortly thereafter.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 04 Apr 2008 17:10:54 -0300

At 04:55 p.m. 04/04/2008, Joe Touch wrote:

>>(draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the 
>>security implications of ICMP on TCP conenctions, it does not 
>>reference the I-D. IIRC, this had already been pointed out by Joe 
>>(?). As far as the specifications are concerned, you shouldn't 
>>bother to fix TCP-based reset attacks if you don't fix the the ICMP-based ones.
>
>(there's no in-window checks that are meaningful, since ICMPs are 
>not guaranteed to be timely) I.e., something stronger than "there's 
>nothing we can do", which is what is implied in the current security 
>considerations.

Ha... So we have been arguing about the ICMP stuff for almost four 
years on the idea that it is too aggressive to require ICMP error 
messages to be in-window, and now we're going to propose to filter 
them out? Seems ironic to me. (And you cannot do it with "frag needed 
and DF bit set". Well, you *could* implement the new PMTUD that does 
not rely on ICMP error messages. But ignoring ICMP error messages 
will increse the PMTUD convergence time).

And, for what is worth, strictly speaking there's no such a thing as 
a TCP MSL, either. TCP's MSL is based on the assumption that the IP 
TTL is decremented at least once every second. And this is not 
warranted, either. There's not such enforcement as there is in, e.g., Delta-t.

>Also ISN randomization (RFC-1948), for similar reasons. Even though 
>some of the RST attacks span the entire window, knowing the ISN can 
>help during the initial handshake and shortly thereafter.

Agreed. (Although the math in "Slipping in the window" does not 
assume the attacker can predict the ISN).

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Fri, 04 Apr 2008 13:21:27 -0700

Fernando Gont wrote:
>> guaranteed to be timely) I.e., something stronger than "there's 
> Ha... So we have been arguing about the ICMP stuff for almost four years 
> on the idea that it is too aggressive to require ICMP error messages to 
> be in-window, and now we're going to propose to filter them out? 

ICMPs are already filtered out for security reasons at firewalls. The 
key here is whether to recommend that action or not.

As to filtering them when they're in- vs out- of window, the issue there 
is whether that even means anything. The point is that with arbitrary 
delays, the location of an ICMP's TCP header with respect to the current 
outstanding window has no useful meaning, so it cannot (and thus should 
not) serve as a useful descriminator.

 > Seems
> ironic to me. (And you cannot do it with "frag needed and DF bit set". 
> Well, you *could* implement the new PMTUD that does not rely on ICMP 
> error messages. But ignoring ICMP error messages will increse the PMTUD 
> convergence time).
> 
> And, for what is worth, strictly speaking there's no such a thing as a 
> TCP MSL, either. TCP's MSL is based on the assumption that the IP TTL is 
> decremented at least once every second. And this is not warranted, 
> either. There's not such enforcement as there is in, e.g., Delta-t.

If there's no MSL, then that's even more reason not to use window 
information to determine the validity of an ICMP. At that point, not 
only might you be receiving a very old ICMP, you might be receiving a 
very recent ICMP for a very old TCP segment.

> Agreed. (Although the math in "Slipping in the window" does not assume 
> the attacker can predict the ISN).

Right - it's not nearly as important as the port randomization for this 
case.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Fri, 4 Apr 2008 14:34:37 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Fernando Gont
> Sent: Friday, April 04, 2008 11:30 AM
> To: [email-masked]
> Subject: [tcpm] Some comments on tcpsecure
> 
> Folks,
> 
> I have not yet reviewed the entire document (but will do). 
> However, reading the security considerations section (and at 
> the risk of sounding our own horn?), I see this document does 
> not reference two closely related wg documents of the tcpm 
> and tsvwg working groups.
> 
> reference the I-D. IIRC, this had already been pointed out by 

Well, if this was really needed we should have fixed this in the
document by now. I think at this stage where most of the issues have
been ironed out, I would excerxise caution before making any changes.
With that I mean if the group strongly feels about citing this reference
then we could add it in some place.

> Joe (?). As far as the specifications are concerned, you 
> shouldn't bother to fix TCP-based reset attacks if you don't 
> fix the the ICMP-based ones.

I am not saying we shouldn't be fixing ICMP based attacks, we should fix
both, but these are separate documents and needs to be treated
seperately. 

> (draft-tsvwg-port-randomization). All the math in the 
> "Slipping in the window" paper assumes TCP implementtions use 
> a small port number subspace for selecting the ephemeral 
> ports. And also assumes that implementations use a 
> trivially-predictable sequence. Clearly, port randomization 
> is a trivial mitigation for both these and all other off-path 
> attacks that require the attacker to guess or know the 

I can only agree that randomization makes the attack harder to
accomplish, but like you noted many systems don't do it today.  Like for
example if you use TCP MD5 the attacks are difficult to be made... So
wondering what is the point being made here? Are you saying that we
should put a reference to the port randomization document? 

-Anantha
> 
> Thanks,
> 
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked] PGP 
> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 05 Apr 2008 02:55:18 -0300

At 05:21 p.m. 04/04/2008, Joe Touch wrote:

>>>not guaranteed to be timely) I.e., something stronger than 
>>>"there's nothing we can do", which is what is implied in the 
>>>current security considerations.
>>messages to be in-window, and now we're going to propose to filter them out?
>
>ICMPs are already filtered out for security reasons at firewalls. 
>The key here is whether to recommend that action or not.

tcpsecure should not talk about what to do with ICMP error messages. 
Just point out that they can be exploited to perform more trivial 
attacks, and reference the ICMP attacks as a reference on what the 
industry has done to solve these issues.

> > Seems
>>ironic to me. (And you cannot do it with "frag needed and DF bit 
>>set". Well, you *could* implement the new PMTUD that does not rely 
>>on ICMP error messages. But ignoring ICMP error messages will 
>>increse the PMTUD convergence time).
>>And, for what is worth, strictly speaking there's no such a thing 
>>as a TCP MSL, either. TCP's MSL is based on the assumption that the 
>>IP TTL is decremented at least once every second. And this is not 
>information to determine the validity of an ICMP.

And no reason to use sequence numbers at all, and no reason for TCP's 
quiet time, and no reason for TCP's TIME-WAIT state, etc., etc., etc. 
 From that purist (??) point of view, TCP would not even work at all.

Joe, don't be more purist than the specifications themselves.

Talk with anybody working on the TCP code of NetBSD, FreeBSD, 
OpenBSD, Linux, or Cisco IOS, and they won't believe you are actually 
arguing about this....for four years. It would look to them as if you 
were doing your best to keep the specs as outdated as possible.

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 05 Apr 2008 03:04:58 -0300

>then we could add it in some place.

There's no actual "change". Just mention that the ICMP issues, and 
reference the ICMP attacks draft for information on the problem, and 
what the industry has done about it.

>both, but these are separate documents and needs to be treated

Exactly. Don't get into recommendations on the ICMP issues. Just 
direct people to the document where this stuff is discussed.

>accomplish, but like you noted many systems don't do it today.

Nowadays, at least FreeBSD, OpenBSD and Linux do it.

>Like for

Yes. Something along the lines of "TCP port randomization 
[draft-ietf-port-randomization] increases the amount of work on the 
side of the attacker by obfuscating the TCP ephemeral port value"

To make my point clear: I'm not saying you should make "statements" 
on whether host should or should implement "icmp attacks" or "port 
randomization". But you should note that the ICMP attacks are easier, 
and direct people to the icmp attacks draft for more information 
about this. And you should note that port randomization is a general 
mitigation-technique for off-path attacks against TCP that require 
more work on the side of the attacker to successfully perform such attacks.

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Sat, 05 Apr 2008 10:17:50 -0700

> At 05:21 p.m. 04/04/2008, Joe Touch wrote:
...
> tcpsecure should not talk about what to do with ICMP error messages. 

I disagree; as you noted, to accomplish any level of protection by 
filtering RSTs etc., ICMPs need to be filtered as well. It can cite your 
doc on the issues, but IMO needs to include a recommendation on 
accompanying requirements.s

...
> From that purist (??) point of view, TCP would not even work at all.

Absolutely - that's the absurdity of *your* point about there being no 
such thing as MSL. However, MSL is irrelevant to ICMP even if (contrary 
to your point above) MSL is meaningful to TCP.

Jo

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sat, 5 Apr 2008 11:29:37 -0700

> Nowadays, at least FreeBSD, OpenBSD and Linux do it.

Just for the sake of record, we have been doing port randomization in
some of our main protocol stacks for about 3 years or so and the
algorithms we follow are more less the ones recommended in the port
randomization draft.

> more work on the side of the attacker to successfully perform 

One point which I wish to add : the long lived nature of some TCP
connections gives enough time for the attacker (attack program) to
successfully penetrate the connection.

I'll leave it to the WG consensus to determine whether citing these
references is ok at this point in the game. 

-Anantha

---

From: Fernando Gont <[email-masked]>
Date: Sat, 05 Apr 2008 17:15:41 -0300

At 02:17 p.m. 05/04/2008, Joe Touch wrote:

>>>>as a TCP MSL, either. TCP's MSL is based on the assumption that 
>>>>the IP TTL is decremented at least once every second. And this is 
>>>>not warranted, either. There's not such enforcement as there is 
>>>>in, e.g., Delta-t.
>>>
>>And no reason to use sequence numbers at all, and no reason for 
>>TCP's quiet time, and no reason for TCP's TIME-WAIT state, etc., 
>>etc., etc. From that purist (??) point of view, TCP would not even work at all.
>
>Absolutely - that's the absurdity of *your* point about there being 
>no such thing as MSL. However, MSL is irrelevant to ICMP even if 
>(contrary to your point above) MSL is meaningful to TCP.

The ICMP attacks drafts used to propose (unfortunately, right now it 
only "documents") a number of mitigation techniques for ICMP-based 
attacks. Among these were:

1) Require ICMP messages to be in window.
2) Don't reset connections in the synchronized (>ESTABLISHED) states 
upno receipt of the so-called ICMP hard errors.

You argument against (1) is that there's not such a timing 
requirement for ICMP messages. If that's your argument, then please 
also propose to remove any sequence number checks and any other 
assumptions on the MSL (e.g., quiet time concept, TIME-WAIT state) 
that are based on timing assumptions of TCP segments (and hence IP 
datagrams) that are *not* required in the protocols, *either*. Or 
well, that at least cannot be enforced. (Again, if you want this, you 
want something like Delta-t).

Your argument against (2) is that...mmm... that would be incorrect, 
because it would assume that every packet is an attack. But you do 
want to advocate ICMP filtering at firewalls.

I'd love to get everybody who's everyday job is to work on the TCP 
code of real TCP stacks. But while I have been in contact with many 
of these people (both for the I-Ds I published at the IETF, and for 
other work), the general idea is that it is a waste of time to argue 
for years what everybody has already been doing for years now (not to 
say 20+ years).

The only real discussion here is how irrelevant we want the IETF specs to be.

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Sat, 05 Apr 2008 13:36:32 -0700

Fernando Gont wrote:
>> such thing as MSL. However, MSL is irrelevant to ICMP even if 
> You argument against (1) is that there's not such a timing requirement 
> for ICMP messages. If that's your argument, then please also propose to 
> remove any sequence number checks and any other assumptions on the MSL 
> (e.g., quiet time concept, TIME-WAIT state) that are based on timing 
> assumptions of TCP segments (and hence IP datagrams) that are *not* 
> required in the protocols, *either*. Or well, that at least cannot be 
> enforced. (Again, if you want this, you want something like Delta-t).

As I said before:

	TCP *has* an MSL requirement (RFC793)
		this means that TCP segments should not live
		in the network beyond approx 2 minutes

	ICMP does *not* have a requirement to respond with an MSL
		so a TCP segment's header can exist inside
		an ICMP packet long after the segment's MSL period

As a result, it remains incorrect to validate a TCP segment inside the 
ICMP as needing to be "in window".

> because it would assume that every packet is an attack. But you do want 
> to advocate ICMP filtering at firewalls.

Correct. If an individual host or subnet wants to assume that ALL ICMPs 
are suspect, then that's its decision - and that already happens at some 
firewalls.

However, it is incorrect to *assume* that a particular kind of ICMP is 
an attack and another is not simply because it is unexpected. That's the 
flaw in #2.

What "everyone implements" isn't the issue; that is covered in BCPs when 
the IETF agrees with it and things like RFC 2525 (Known TCP 
Implementation Problems) when the IETF does not feel it is appropriate 
to change the standard merely to align with what is deployed.

In this case, since ICMPs *are* delayed, I don't think it is appropriate 
to align ICMP checks with what is deployed.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 05 Apr 2008 20:51:05 -0300

>                 in the network beyond approx 2 minutes

Yes, and this requirement cannot be met, as it is based on the 
assumption that the IP TTL can be enforced. (Not to say that the MSL 
sort of imposes a requirement on the TTL you set in IP packets. If 
you set a TTL of say 240, then the TTL becomes 4 minutes, and 2*MSL 
becomes eight minutes.

As a result, if anything, this is as incorrect as requiring ICMPs to 
be in window. Well, unless you run TCP on anything other than IP....

>As a result, it remains incorrect to validate a TCP segment inside 
>the ICMP as needing to be "in window".

If there's an error, the the window won't advance, and in the event 
the window does advance, then the error was not really "hard". And it 
would have been incorrect to abort the TCP connection. (see e.g., 
Clark's paper).

>Correct. If an individual host or subnet wants to assume that ALL 
>ICMPs are suspect, then that's its decision - and that already 
>happens at some firewalls.

Welcome to the real world. We're suspicious by default.

>What "everyone implements" isn't the issue; that is covered in BCPs 
>when the IETF agrees with it and things like RFC 2525 (Known TCP 
>Implementation Problems) when the IETF does not feel it is 
>appropriate to change the standard merely to align with what is deployed.

What "everyone implements" isn't the issue? ahem... "rough consensus 
and running code".

There's no code that runs what you're describing, Joe. Everybody is 
doing what is described in the ICMP attacks draft.

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Sat, 05 Apr 2008 18:02:33 -0700

Fernando Gont wrote:
> sort of imposes a requirement on the TTL you set in IP packets. If you 
> set a TTL of say 240, then the TTL becomes 4 minutes, and 2*MSL becomes 
> eight minutes.
> 
> As a result, if anything, this is as incorrect as requiring ICMPs to be 
> in window. Well, unless you run TCP on anything other than IP....

If you want to win this part of the argument, then - as you note - 
window information is never useful within TCP. What's the point of this 
straw-man?

> If there's an error, the the window won't advance, and in the event the 
> window does advance, then the error was not really "hard". And it would
> have been incorrect to abort the TCP connection. (see e.g., Clark's paper).

The ICMP error isn't "TCP failing to make progress" - if you want that 
one, please create a new ICMP error type. Whether you do or not, please 
stop trying to imply those semantics to the current ICMP errors.

>> ICMPs are suspect, then that's its decision - and that already happens 
>> at some firewalls.
> 

Postel's rule applies; be conservative in what you do, be liberal in 
what you receive. You can be suspicious all you want - but unfounded 
suspicion isn't appropriate.

> What "everyone implements" isn't the issue? ahem... "rough consensus and 
> running code".

It's rough consensus AND running code. Not 'running code trumps everything'.

> doing what is described in the ICMP attacks draft.

Popular vote does not determine correctness. Part of the problem is that 
there are some people who've deployed prototype code and convinced 
everyone it's appropriate. That is NOT how protocol specifications are 
determined.

We've had this debate before. If there's nothing new to add, let's let 
others chime in.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sat, 5 Apr 2008 19:33:48 -0700

> Popular vote does not determine correctness. Part of the 
> problem is that there are some people who've deployed 
> prototype code and convinced everyone it's appropriate. That 
> is NOT how protocol specifications are determined.
> 
> We've had this debate before. If there's nothing new to add, 
> let's let others chime in.

I'll chime in, my few cents follows :

Protocol specifications do evolve from time to time. For example, if
most of the devices which is running in the internet is already
implementing what is being proposed for quite sometime, the proof is in
the pudding. In such cases it CAN be considered for standardization and
also this (ICMP attacks) is already a WG document and I think making
forward progress is important here. So what is being said above comes
across as totally out of place given the current context. Well, there
are tons of examples where "prototype" code has become a standard,
should I start giving examples, I won't since everyone who has been
around knows this is a fact and I am in no mood to spend my energy in
debating something so obvious. May be someone's definition of prototype
code isn't the same as mine, then that is a different discussion
altogether ;-)

-Anantha

---

From: Fernando Gont <[email-masked]>
Date: Sun, 06 Apr 2008 07:40:44 -0300

At 10:02 p.m. 05/04/2008, Joe Touch wrote:

>>assumption that the IP TTL can be enforced. (Not to say that the 
>>MSL sort of imposes a requirement on the TTL you set in IP packets. 
>>If you set a TTL of say 240, then the TTL becomes 4 minutes, and 
>>2*MSL becomes eight minutes.
>>As a result, if anything, this is as incorrect as requiring ICMPs 
>>to be in window. Well, unless you run TCP on anything other than IP....
>
>window information is never useful within TCP. What's the point of 
>this straw-man?

That if you want to be picky, that's where you should probably start. 
You talk about how incorrect it would be to enforce ICMP messages to 
be in-window... but even the most basic timing assumptions in TCP are 
not "correct", either.

Yes, "It just works". But that does not imply "correctness".

[...]
>>the window does advance, then the error was not really "hard". And it would
>The ICMP error isn't "TCP failing to make progress" - if you want 
>that one, please create a new ICMP error type. Whether you do or 
>not, please stop trying to imply those semantics to the current ICMP errors.

We're not here to re-hash history, are we?

>Popular vote does not determine correctness. Part of the problem is 
>that there are some people who've deployed prototype code and 
>convinced everyone it's appropriate. That is NOT how protocol 
>specifications are determined.

There's a recent and wonderful book by old-timer John Day, in which 
he explains that the internet protocols themselves were what you call 
"prototype" (and I'm referencing that particular book just for the 
fact that the author is great, and I love his book). So... I find 
your comment a little bit ironic. :-)

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Sun, 06 Apr 2008 13:05:39 -0700

Let's try to move this forward constructively...

Let's assume that we all want to make TCP's processing of error messages 
depend on the coarse connection state - i.e., different interpretation 
of errors in pre-established vs. established states.

	This is basically how the current TCP ICMP processing
	is already defined, and would extend it to be more uniform,
	which seems reasonable.

Let's further assume, that in the established state, that "making 
progress" should invalidate receipt of error messages to the contrary.

	This is a *departure* from current TCP ICMP processing, which
	basically says that errors trump progress. Whether this
	is reasonable depends on how slowly you want TCP to
	make progress while receiving legitimate errors
	(e.g., due to flakey links, multipath/routing errors, etc.),
	vs. making TCP robust to such behavior.

	I do believe we need to make this work in the case of
	non-malicious behavior. Only then should we consider
	whether or not it affords obfuscation protection against
	attackers.

	Given this case, then *progress* is the metric. That implies:
		- cache received ICMPs and log window state
		- determine if the window moves after the ICMP
		is received; if so, drop that ICMP

One key issue above: it is NOT dependent on the window data in the ICMP 
payload, for two reasons:

	1) (my point) ICMPs are not required to be issued in a timely
	fashion, or for every individual error, a legitimate situation
	could involve receiving an old ICMP about an endpoint failure,
	without receiving further updates on any particular schedule

	2) (Fernando's point) ICMPs are currently implemented widely
	as not being issued in a timely fashion, with the same results
	as #1

I.e., it doesn't matter if you design for spec or common 
implementations; either way, ICMP payload window information is not 
relevant to the "making progress" issue.

If you want to recommend that we change ICMP interpretation when making 
progress, then base your decision on a direct metric of making progress, 
not an incorectly inferred one.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sun, 06 Apr 2008 19:38:34 -0300

At 05:05 p.m. 06/04/2008, Joe Touch wrote:

(Meta comment: The current version of the ICMP attacks draft is meant 
for the Informational path. I believe I have removed/rephrased those 
senteces which seemed to "propose" the mitigation-techniques, rather 
than simply document them. If I did a good job in this last revision, 
the doc shouldn't be far from being ready to be shipped to the IESG. 
The soft errors draft is already there. These two drafts, together 
with another one some of us will be submitting anytime soon would be 
of great help as a basis for further work that would include what you 
sketch bellow.)

Please see my comments inline....

>Let's try to move this forward constructively...

Agreed.

[....]
>                 is received; if so, drop that ICMP

(Thinking out loud, with no coffee in the last few hours ;-) ): I'd 
also add "Discard the ICMP message if there's no data in flight to 
the destination when the ICMP error message is received" (i.e., in 
such a scenario, there's no "forward progress" to be made).

>One key issue above: it is NOT dependent on the window data in the 
>ICMP payload, for two reasons:
>

Agreed. You may say "making progress" and "requiring the TCP SEQ in 
the ICMP payload to be 'in-window'" are two different issues.

The TCP SEQ check would help a bit in those scenarios in which an 
attacker might be able to spoof an ICMP error message, and cause the 
connection to be stuck for a little while (e.g., by means of causing 
congestion). That is, it would require more packets on the side of 
the attacker.

However, if TCP waits for USER_TIMEOUT to check whether the 
connection is making forward progress, then this is basically the 
"hard errors should be considered to indicate soft errors when 
received for connections in any of the synchronized states" behavior, 
and thus an attacker could not exploit the so-called ICMP hard errors 
to perform reset attacks.

(i.e., the "hard errors should be considered to indicate soft errors 
when received for connections in any of the synchronized states" 
becomes a degenerate case of the "checking for progress on the TCP 
connection" when TCP waits for USER_TIMEOUT seconds before concluding 
whether the connection is making progress or not).

(FWIW, the TCP SEQ is of a little bit more of help for PMTUD, as 
during what I called 'Initial Path-MTU Discovery', you probably don't 
want to wait, so that you get a good convergence time for the PMTUD).

Kind regards, and thanks for the clarification above!

---

From: Joe Touch <[email-masked]>
Date: Sun, 06 Apr 2008 22:05:22 -0700

Fernando Gont wrote:
> the doc shouldn't be far from being ready to be shipped to the IESG. The 
> soft errors draft is already there. These two drafts, together with 
> another one some of us will be submitting anytime soon would be of great 
> help as a basis for further work that would include what you sketch 
> bellow.)
> 
> (Thinking out loud, with no coffee in the last few hours ;-) ): I'd also 
> add "Discard the ICMP message if there's no data in flight to the 
> destination when the ICMP error message is received" (i.e., in such a 
> scenario, there's no "forward progress" to be made).

OK - again, that has nothing to do with the contents of the ICMP message.

> Agreed. You may say "making progress" and "requiring the TCP SEQ in the 
> ICMP payload to be 'in-window'" are two different issues.

Agreed.

> congestion). That is, it would require more packets on the side of the 
> attacker.

In those cases, I still see the contents of the ICMP to be moot (w.r.t. 
window). That info is useful only if:
	- ICMPs are known to be returned in a timely fashion
	(and there's no way of knowing)
	OR
	- there's some way to differentiate between legitimate
	ICMPs and attack ICMPs

Since neither is the case, this is a moot issue. I do not agree that 
checking the TCP SEQ in the content of an ICMP is ever appropriate.
	
> However, if TCP waits for USER_TIMEOUT to check whether the connection 
> is making forward progress, then this is basically the "hard errors 
> should be considered to indicate soft errors when received for 
> connections in any of the synchronized states" behavior, and thus an 
> attacker could not exploit the so-called ICMP hard errors to perform 
> reset attacks.

Waiting that long defeats the purpose of the errors - to terminate 
connections more rapidly than TCP would otherwise. That is, IMO, too far.

> when received for connections in any of the synchronized states" becomes 
> a degenerate case of the "checking for progress on the TCP connection" 
> when TCP waits for USER_TIMEOUT seconds before concluding whether the 
> connection is making progress or not).
> 
> (FWIW, the TCP SEQ is of a little bit more of help for PMTUD, as during 
> what I called 'Initial Path-MTU Discovery', you probably don't want to 
> wait, so that you get a good convergence time for the PMTUD).

I'd have to think further to see if this appropriate - i.e., if done 
only once during a connection, before a wrap, then the SEQ might be 
appropriate to check, but only within that period.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Mon, 7 Apr 2008 08:14:15 +0300 (EEST)

> 	as not being issued in a timely fashion, with the same results

What is "timely fashion" in 2)?  What is not?  What are the scenarios 
where this occurs?

ICMP error generation has always seemed "timely" to me.  The only 
exception, in a way, that I've noticed is if ICMP error origination 
rate-limiter is active at the moment the offending packet is received. 
The reason I say "in a way" is that the text above makes me think the 
point is that ICMP error generation is delayed (which rate-limiters 
don't do) rather than skipped altogether. Is point 2) referring to 
rate-limiting or something else?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Sun, 06 Apr 2008 22:21:19 -0700

> What is "timely fashion" in 2)?  What is not?  What are the scenarios 

Routers are not required to return ICMPs on any particular timescale.

Timely most specifically would mean "within the MSL during which the 
original TCP segment was intended to be limited to"; most practically, 
it might be "within one MSL of when the original TCP segment was 
received and triggered the corresponding ICMP".

Non-timely would definitely mean "more than one MSL after the TCP 
segment that triggered the ICMP event was received". That could occur 
when a router paces its ICMP output (as recommended in RFC 1812), and 
when an implementation uses a tail-drop queue for that logging.

> rate-limiter is active at the moment the offending packet is received.

Exactly.

> rate-limiting or something else?

The case I described is when rate limiting causes a delay. Another case 
would be when messages are queued up and only periodically handled, and 
that router's control plane is under significant load.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 6 Apr 2008 23:26:13 -0700

<snip>

> Routers are not required to return ICMPs on any particular timescale.

Routers are not going to delay the ICMP message generation
unnecessarily. In most cases the ICMP messages are going to be generated
in orderly and timely fashion.

> 
> Timely most specifically would mean "within the MSL during 
> which the original TCP segment was intended to be limited 
> to"; most practically, it might be "within one MSL of when 
> the original TCP segment was received and triggered the 
> corresponding ICMP".
> 
> Non-timely would definitely mean "more than one MSL after the 
> TCP segment that triggered the ICMP event was received". That 
> could occur when a router paces its ICMP output (as 
> recommended in RFC 1812), and when an implementation uses a 
> tail-drop queue for that logging.

- Rate-limiting/ICMP messages being dropped can happen anytime/anywhere,
but overly delaying ICMP isn't common. Anyways the end-points
responsibility is to be robust and not fooled by the presense or the
absense of the ICMP messages. PMTU blackhole detection and recovery is
there for a reason. Since you cannot rely on the ICMP message being
generated always, if one is generated then putting some additional
checks to validate it doesn't look far-fetched, IMO. Please see below.

> The case I described is when rate limiting causes a delay. 
> Another case would be when messages are queued up and only 
> periodically handled, and that router's control plane is 
> under significant load.

Even if all the conditions which you describe above are true, in most
cases the packet is going to dropped before sending a ICMP message.
(Eg;- DF bit set but needs to be fragment etc.,) in which case the
sender SNDUNA is not going to advance since it is not going to get an
ACK from the peer. This means that sender is going to see the ICMP
message (assuming one is going to generated) as the first respone to the
TCP segment it had sent on that particular TCP connection (forget
bi-directional data for a moment). OR is the scenario which is causing a
worry is that when the ACK arrived and advanced the SNDUNA, but the ICMP
arrived pretty late whose sequence # did not match and hence we dropped
it ( due to the recommendation of the draft), if so what is the big
deal? 

In a nutshell, the benefits of adding robustness by dropping the
suspicious ICMP messages far outwiegh the corner cases (which I am still
not convinced that those are real) where we don't process an "outdated"
ICMP message.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Apr 2008 06:33:57 -0700

Anantha Ramaiah (ananth) wrote:
...
> not convinced that those are real) where we don't process an "outdated"

The bulk of the benefits of robustness are afforded by having ICMPs 
depend on the state and progress of the connection.

We have got to get away from this notion, BTW, that 'unexpected messages 
imply an attack'. The only thing such messages indicate is the inability 
of the programmer to see a valid corner case.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 07 Apr 2008 12:14:36 -0300

At 02:05 a.m. 07/04/2008, Joe Touch wrote:

>>attacker might be able to spoof an ICMP error message, and cause 
>>the connection to be stuck for a little while (e.g., by means of 
>>causing congestion). That is, it would require more packets on the 
>>side of the attacker.
>
>In those cases, I still see the contents of the ICMP to be moot 
>(w.r.t. window). That info is useful only if:

If anything, isn't this the case for any type of packet? After all, 
any packet can get queued in a router or be delayed whilie transiting 
a link....

>checking the TCP SEQ in the content of an ICMP is ever appropriate.

Well, I do know that you don't like the idea, but the systems I know 
of will not consider a packet legitimate unless there's enough reason 
for that. For ICMPs, the bar for that is the SEQ contained in the 
payload. That's what everybody has been doing for quite some time.

>>received for connections in any of the synchronized states" 
>>behavior, and thus an attacker could not exploit the so-called ICMP 
>>hard errors to perform reset attacks.
>

Well, that's just a matter of policy. In any case, Clark's RFC on 
"Fault Isolation and Recovery" and even "The Design of the DARPA..." 
seem to support this idea: data transfers should work when there is 
at least a working path to do the transfer.
As I have seen you have mentioned a number of times, TCP is not 
supposed to be optimized for any scenario (e.g., multi-path 
scenarios). So if there's a working path, I think that for robustness 
sake the connection should not be aborted.

In any case, I don't think we'd even have to stick to any particular 
timeout. Particularly, given that we can accommodate existing 
implementations (hard errors -> soft errors) as a degenerate case of the above.

>>(i.e., the "hard errors should be considered to indicate soft 
>>errors when received for connections in any of the synchronized 
>>states" becomes a degenerate case of the "checking for progress on 
>>the TCP connection" when TCP waits for USER_TIMEOUT seconds before 
>>concluding whether the connection is making progress or not).
>>during what I called 'Initial Path-MTU Discovery', you probably 
>>don't want to wait, so that you get a good convergence time for the PMTUD).
>

Most of all, the check is needed once at the beginning of the connection.
Then, it might be nice to do it after the 10-minute PMTUD timeout 
when you want to discover the PMTU again. Although at that point 
(t>10 minutes) it wouldn't be much of a problem to just check for 
progress on the connection (what's most important is to avoid delays 
at he beginning of the connection, as that would hurt interactive applications)

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Apr 2008 08:40:07 -0700

Fernando Gont wrote:
> If anything, isn't this the case for any type of packet? After all, any 
> packet can get queued in a router or be delayed whilie transiting a 
> link....

Routers are supposed to forward packets in a timely fashion, but are 
encouraged to delay control plane event processing when loaded - both 
are in RFC 1812.

I.e., for forwarding this is required, but for ICMP the contrary us 
allowed and encouraged if needed.

> Well, I do know that you don't like the idea, but the systems I know of 
> will not consider a packet legitimate unless there's enough reason for 
> that. For ICMPs, the bar for that is the SEQ contained in the payload. 
> That's what everybody has been doing for quite some time.

Again, known implementation bugs aren't the issue - and since seq 
checking isn't required, dropping packets due to that check qualifies 
IMO as an implementation bug.

But this is still somewhat off topic if there's a way to get 95% of the 
way there without doing a seq check, which is what I'm suggesting. That 
would correct the *intent* of the current code without *needing to 
change the current specs* (which is the only way to *require* timely ICMPs).

> Well, that's just a matter of policy. In any case, Clark's RFC on "Fault 
> Isolation and Recovery" and even "The Design of the DARPA..." seem to 
> support this idea: data transfers should work when there is at least a 
> working path to do the transfer.
> As I have seen you have mentioned a number of times, TCP is not supposed 
> to be optimized for any scenario (e.g., multi-path scenarios). So if 
> there's a working path, I think that for robustness sake the connection 
> should not be aborted.

Robustness also allows signalled connection faults to recover quickly, 
rather than on the same timescale as a 'no message' timeout. Yes, 
though, the devil is in the detail of what that timeout would be.

> implementations (hard errors -> soft errors) as a degenerate case of the 

That's assuming the worst timeout, IMO, which is a particular timeout 
value I disagree with.

> Then, it might be nice to do it after the 10-minute PMTUD timeout when 
> you want to discover the PMTU again. Although at that point (t>10 
> minutes) it wouldn't be much of a problem to just check for progress on 
> the connection (what's most important is to avoid delays at he beginning 
> of the connection, as that would hurt interactive applications)

The first one can easily have a seq num check, since the connection 
isn't open long enough for a legitimate delay. However, the subesquent 
ones don't seem to have that luxury, IMO.

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 7 Apr 2008 11:34:00 -0700

> key here is whether to recommend that action or not.

And, IMHO, hat off, we're not.  Not here anyway.

This document has generated enough controversy on its own.  Hitching it
to another controversial document guarantees even slower progress.
Point off to the other documents that discuss the ICMP problem and move
on.  Yes there's a huge hole that someone's network architect needs to
plug, but the purpose of this document is not to be that architect; the
purpose of this document is to specify a standard protocol extension to
address the problem of off-path TCP control message spoofing.  Pointing
off to documents that discuss other problems in detail is helpful and
useful.

IMHO.

-- 
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://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Apr 2008 13:31:28 -0700

> And, IMHO, hat off, we're not.  Not here anyway.

If that's the case, then what's the point of protecting TCP this way?

If ICMPs aren't filtered out, then they remain a simpler attack vector, 
and thus the protections afforded are moot.

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 7 Apr 2008 13:57:11 -0700

> and thus the protections afforded are moot.

You understand, of course, that our hypothetical network architect might
read these documents in the other order - ICMP protections/ingress
filtering first, then tcpsecure.   In that sequence the point is closing
the hole remaining after ICMP is blocked and assuming that IPSec (or
however it's spelled) is ruled out.

Again, the purpose of this document is to standardize a protocol
extension that makes a specific attack more difficult.  It is not a
primer on securing TCP against all attacks - or even all spoofing
attacks.  It's not the job of a standards document to mandate all
possible (or even all relevant) countermeasures to all related attacks.
This document needs to point to the ICMP document - perhaps strongly -
but needn't RECOMMEND, in a 2119 sense, anything therein.  And given that
this is a standards document, I don't think it should recommend them
either.

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Apr 2008 14:02:26 -0700

> this is a standards document, I don't think it should recommend them

Fair enough. It can warn - in the security considerations - that these 
protections assume corresponding protections on ICMPs, however. I.e., it 
  would be incorrect to recommend, but it can warn that "without 
corresponding ICMPs, this document may not provide the desired protection"

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 7 Apr 2008 14:24:00 -0700

> corresponding ICMPs, this document may not provide the desired protection"

I think the quoted text, including a citation to an appropriate
document, would be an excellent addition to the security concerns
section of this document.  That's speaking as an individual.

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 7 Apr 2008 18:45:53 -0700

Ted, 

> Behalf Of Ted Faber
> Sent: Monday, April 07, 2008 2:24 PM
> To: Joe Touch
> Cc: [email-masked]; Fernando Gont
> Subject: Re: [tcpm] Some comments on tcpsecure
> 
> > protections assume corresponding protections on ICMPs, 
> however. I.e., 
> > it  would be incorrect to recommend, but it can warn that "without 
> I think the quoted text, including a citation to an 
> appropriate document, would be an excellent addition to the 
> security concerns section of this document.  That's speaking 
> as an individual.

Like it has been pointed out above, it would be incorrect to make any
recommendation about ICMP or any other form of attack vectors in the
tcpsecure doc since this document is not meant to be a repository of all
currently known ( and going to be discovered in the near future ;-)
attacks on TCP. So, IMO the verbiage needs to be chosen carefully if the
consensus is to provide a pointer to the ICMP doc in the security
consideration section. I would like to simply put an informative note
telling "spoofed ICMP packets may also result in TCP connection
stability issues, and this is discussed in more depth in......." or
something of that sort. 

$0.02,
-Anantha

---

From: Ted Faber <[email-masked]>
Date: Mon, 7 Apr 2008 18:58:30 -0700

> stability issues, and this is discussed in more depth in......." or

I'm not writing the document, but Joe's words [lightly edited] look good
to me:

"Unless implementors address spoofed ICMP messages[], the mitigations
specified in this document may not provide the desired protection."

Write what you want, but that seems to be exactly what needs to be said,
and cut and paste is easy.

I have no attachment to those particular words, but capture the thoughts
because I'd rather not have this discussion again.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 08 Apr 2008 16:03:56 -0300

At 12:40 p.m. 07/04/2008, Joe Touch wrote:

>>any packet can get queued in a router or be delayed whilie 
>>transiting a link....
>
>encouraged to delay control plane event processing when loaded - 
>both are in RFC 1812.
>

I'd bet that it is more likely that packets get delayed longer for 
congestion probems or while transiting a link (e.g., a satellite 
link) than for that of delaying control plane event processing when loaded.

>>>Since neither is the case, this is a moot issue. I do not agree 
>>>that checking the TCP SEQ in the content of an ICMP is ever appropriate.
>>Well, I do know that you don't like the idea, but the systems I 
>>know of will not consider a packet legitimate unless there's enough 
>>reason for that. For ICMPs, the bar for that is the SEQ contained 
>>in the payload. That's what everybody has been doing for quite some time.
>
>checking isn't required, dropping packets due to that check 
>qualifies IMO as an implementation bug.

Well, I guess we have to agree to disagree. :-)

>But this is still somewhat off topic if there's a way to get 95% of 
>the way there without doing a seq check, which is what I'm 
>suggesting. That would correct the *intent* of the current code 
>without *needing to change the current specs* (which is the only way 
>to *require* timely ICMPs).

ICMP code has been for a long time (>20+ years, in some cases) to do 
"hard errors -> soft errors". The TCP SEQ check was originally 
implemented in Linux as a general validation check. Then applied in 
virtually all stacks for the same reason.
The TCP SEQ check is particularly useful as a mitigation against 
PMTUD attacks... and some have seen as something quicker/easier to 
implement than the mechanism proposed in my draft (although FWIW, I 
implemented the mechanism myself for OpenBSD, and it wasn't what pne 
would call "complex" at all...)

>>>>behavior, and thus an attacker could not exploit the so-called 
>>>>ICMP hard errors to perform reset attacks.
>>>
>>"Fault Isolation and Recovery" and even "The Design of the 
>>DARPA..." seem to support this idea: data transfers should work 
>>when there is at least a working path to do the transfer.
>>scenarios). So if there's a working path, I think that for 
>>robustness sake the connection should not be aborted.
>
>Robustness also allows signalled connection faults to recover 
>quickly, rather than on the same timescale as a 'no message' 
>timeout. Yes, though, the devil is in the detail of what that timeout would be.

You say it allows a connection to recover quickly, but... why would 
it actually recover, if you are not affecting the path that packets follow?

>>In any case, I don't think we'd even have to stick to any 
>>particular timeout. Particularly, given that we can accommodate 
>>existing implementations (hard errors -> soft errors) as a 
>>degenerate case of the above.
>
>That's assuming the worst timeout, IMO, which is a particular 
>timeout value I disagree with.

That's how the Internet has worked during the last 20+ years. 
BSD-derived and Mentat-derived implementations have always done this.

>>>>states" becomes a degenerate case of the "checking for progress 
>>>>on the TCP connection" when TCP waits for USER_TIMEOUT seconds 
>>>>before concluding whether the connection is making progress or not).
>>>I'd have to think further to see if this appropriate - i.e., if 
>>>done only once during a connection, before a wrap, then the SEQ 
>>>might be appropriate to check, but only within that period.
>>progress on the connection (what's most important is to avoid 
>>delays at he beginning of the connection, as that would hurt 
>>interactive applications)
>
>isn't open long enough for a legitimate delay. However, the 
>subesquent ones don't seem to have that luxury, IMO.

Well, that wouldn't be a big deal. After all, the delay I'm more 
concerned about would be the one when the connection has just been 
established (as it would affect interactive applications). Although 
one might argue that with http persistent-connections, connections 
could be affected by the delay made after the 10-minute PMTUD-timeout.....

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Apr 2008 12:56:09 -0700

Fernando Gont wrote:
...
>> the way there without doing a seq check, which is what I'm suggesting. 
>> That would correct the *intent* of the current code without *needing 
>> to change the current specs* (which is the only way to *require* 
>> timely ICMPs).
> 
> The TCP SEQ check is particularly useful as a mitigation against PMTUD 
> attacks... and some have seen as something quicker/easier to implement 
> than the mechanism proposed in my draft (although FWIW, I implemented 
> the mechanism myself for OpenBSD, and it wasn't what pne would call 
> "complex" at all...)

I'd like to see a mechanism that's sufficiently easy to implement that 
accomplishes the intent, even if it differs from what's currently 
deployed. That presumes we're trying to find a good solution, rather 
than document the existing deployed solution.

...
> You say it allows a connection to recover quickly, but... why would it 
> actually recover, if you are not affecting the path that packets follow?

Recovery could involve the application terminating a poor connection in 
favor of a better alternate, e.g., to a different IP address. By 
prolonging the agony, we're failing to indicate that the connection is 
having a substantial problem.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 08 Apr 2008 17:36:36 -0300

At 04:56 p.m. 08/04/2008, Joe Touch wrote:

>>>But this is still somewhat off topic if there's a way to get 95% 
>>>of the way there without doing a seq check, which is what I'm 
>>>without *needing to change the current specs* (which is the only 
>>>way to *require* timely ICMPs).
>>ICMP code has been for a long time (>20+ years, in some cases) to 
>>do "hard errors -> soft errors". The TCP SEQ check was originally 
>>implemented the mechanism myself for OpenBSD, and it wasn't what 
>>pne would call "complex" at all...)
>
>I'd like to see a mechanism that's sufficiently easy to implement 
>that accomplishes the intent, even if it differs from what's 
>currently deployed. That presumes we're trying to find a good 
>solution, rather than document the existing deployed solution.

As I said, I did implement the PMTUD stuff in the icmp attacks draft. 
It now ships with OpenBSD and NetBSD, at least. And it's really easy 
to implement.

Regarding the mechanism you want to see (I'd say it's the same thing 
that's currently in the draft, except for what happens after the 
10-minute timeout), it will be the subject of some future 
standards-track draft. This one is informational, and documents what's done.

>Recovery could involve the application terminating a poor connection 
>in favor of a better alternate, e.g., to a different IP address. By 
>prolonging the agony, we're failing to indicate that the connection 
>is having a substantial problem.

Well, this is even more agressive than the soft errors stuff/draft we 
have argued about for years. However, applications can already 
benefit of the soft errors behavior (what's described in the draft), 
but cannot currently benefit from what you propose.
They only loop through the A records while trying to establish a 
connection... but they don't loop through them if there's an error 
afterwards. The only exception to this might be an MTA.

Kind regards,

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 8 Apr 2008 15:28:27 -0700

> 
> I'd like to see a mechanism that's sufficiently easy to 
> implement that accomplishes the intent, even if it differs 
> from what's currently deployed. That presumes we're trying to 
> find a good solution, rather than document the existing 
> deployed solution.

IMO, there is nothing wrong in documenting the existing practices
prevailing in the internet. There is no point in waiting for a "good
solution" which is non-existent currently and supposed to serve as a
replacement for the current undocumented but widely accepted and
deployed solution. 

$0.02,
-Anantha