Subject: [tcpm] Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt

From: Fernando Gont <[email-masked]>
Date: Thu, 18 May 2006 04:01:23 -0300

Joe,

In section 4 ("ICMP") of the document, in my opinion there are some 
issues that are missing.

In the case of the ICMP-based connection reset attack, the main 
counter-measure is to change TCP's reaction to hard errors. The 
rationale for this is included in the ICMP attacks draft. If the 
counter-measure was just to check the TCP seq number, then, as long 
as the RFCs are concerned, that would give us the same level of 
"protection" TCP already has for TCP-based reset attacks (i.e., 
require the forged packet to be "in window"). Thus, ICMP would still 
be "the weakest link in the chain".

As for the filtering of ICMP messages, it is interesting to note that 
while ICMP messages can be inserted anywhere in the network (without 
even needing to spoof the source IP address), address spoofing *is* 
needed in the ICMP payload, and thus ingress/egress filtering can be 
performed based on the ICMP payload.

Kindest regards,

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 May 2006 12:00:32 +0300 (EEST)

On Thu, 18 May 2006, Fernando Gont wrote:
> As for the filtering of ICMP messages, it is interesting to note that while 
> ICMP messages can be inserted anywhere in the network (without even needing 
> to spoof the source IP address), address spoofing *is* needed in the ICMP 
> payload, and thus ingress/egress filtering can be performed based on the ICMP 
> payload.

I hope you're not suggesting that implementations (e.g., routers) 
would need to verify the payload of ICMP error messages they're 
transiting for this to be effective..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fernando Gont <[email-masked]>
Date: Thu, 18 May 2006 06:39:59 -0300

At 06:00 18/05/2006, Pekka Savola wrote:

>>As for the filtering of ICMP messages, it is interesting to note 
>>that while ICMP messages can be inserted anywhere in the network 
>>(without even needing to spoof the source IP address), address 
>>spoofing *is* needed in the ICMP payload, and thus ingress/egress 
>>filtering can be performed based on the ICMP payload.
>

This filtering could be implemented in firewalls, for example.

My point was that the draft says
"    As a result,
    many networks filter all ICMP packets because validation may not be
    possible, especially because they can be injected from anywhere in a
    network, and so cannot be selectively address filtered."

ICMP messages can be filtered with the same selectiveness than IP datagrams.

Whether or not it's convenience from a performance point of view is a 
different issue.

Kindest regards,

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 May 2006 13:15:05 +0300 (EEST)

> Whether or not it's convenience from a performance point of view is a 

Agreed to certain extent.  Firewalls could block "external payload 
spoofing" from interfering with internal sessions, but as such ICMP 
payload filtering is not possible (in practice) in the same (or 
roughly same) places where ingress filtering is performed, it is not 
as useful for more generic protection.

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 May 2006 07:25:42 -0700

Fernando Gont wrote:
> counter-measure is to change TCP's reaction to hard errors.

The primary countermeasure is already deployed - to block ICMPs. This 
does not require a modification to TCP. This allows the filtering to 
determine the level of protection afforded, rather than wiring all TCPs 
to include such filtering natively. The latter essentially deprecates 
the capabilities afforded by hard errors in trusted environments - e.g., 
behind firewalls, inside VPNs, etc., and seems overkill.

The document already cites that draft (I can issue a quick update to fix 
the ref to the Feb 06 TCPM version, if that matters).

> The 
> counter-measure was just to check the TCP seq number, then, as long as 
> the RFCs are concerned, that would give us the same level of 
> "protection" TCP already has for TCP-based reset attacks (i.e., require 
> the forged packet to be "in window"). Thus, ICMP would still be "the 
> weakest link in the chain".
> 

Filtering on the payload is less useful than filtering on the source 
address; the ICMP packet may be allowed to take a path that the source 
address is not, so it's not necessarily appropriate to make filtering 
decisions on the payload.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 May 2006 01:39:10 -0300

At 11:25 18/05/2006, Joe Touch wrote:

>The primary countermeasure is already deployed - to block ICMPs. 
>This does not require a modification to TCP. This allows the 
>filtering to determine the level of protection afforded, rather than 
>wiring all TCPs to include such filtering natively. The latter 
>essentially deprecates the capabilities afforded by hard errors in 
>trusted environments - e.g., behind firewalls, inside VPNs, etc., 
>and seems overkill.

I strongly disagree. And so do existing implementations.

All BSD-derived and Mentat-derived TCP/IP stacks treat the so-called 
"hard errors" as "soft errors".
I don't know what Microsoft Windows' stack is derived from. But they 
published an advisory on this issue, and their patch is supposed to 
treat "hard errors" as "soft errors", too.

Cisco treats the "so called" hard errors as "soft errors", too, IIRC.

On the other hand, I disagree that "blocking ICMPs" is already 
deployed. Try traceroute. Try ping. They still work. PMTUD works to a 
large extent, too.

>The document already cites that draft (I can issue a quick update to 
>fix the ref to the Feb 06 TCPM version, if that matters).

My point is that the antispoof draft is not citing the ICMP attacks 
draft properly. You just mention the TCP seq checking, when that's 
less than 10% of the draft.

>>The rationale for this is included in the ICMP attacks draft. If 
>>the counter-measure was just to check the TCP seq number, then, as 
>>long as the RFCs are concerned, that would give us the same level 
>>of "protection" TCP already has for TCP-based reset attacks (i.e., 
>>require the forged packet to be "in window"). Thus, ICMP would 
>>still be "the weakest link in the chain".
>address; the ICMP packet may be allowed to take a path that the 
>source address is not, so it's not necessarily appropriate to make 
>filtering decisions on the payload.

I don't get your point. I don;t see the difference between 
ingress/egress filtering based on the outer IP datagram (for IP 
packets), and based on the inner IP datagrams (for ICMP error messages).

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 May 2006 01:39:10 -0300

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 May 2006 22:40:03 -0700

Fernando Gont wrote:
>> determine the level of protection afforded, rather than wiring all 
>> TCPs to include such filtering natively. The latter essentially 
>> deprecates the capabilities afforded by hard errors in trusted 
>> environments - e.g., behind firewalls, inside VPNs, etc., and seems 
>> overkill.
> 
> On the other hand, I disagree that "blocking ICMPs" is already deployed. 
> Try traceroute. Try ping. They still work. PMTUD works to a large 
> extent, too.

In environments where security is an issue, where connections are 
vulnerable to ICMP attacks, ICMP is blocked. Try pinging hosts behind 
firewalls or NATs.

To the extent that existing implementations violate RFC1122, they do. 
This isn't the first case of such errors; an RFC was written documenting 
a number of TCP bugs a while back. ;-)

> draft properly. You just mention the TCP seq checking, when that's less 
> than 10% of the draft.

I can add the fact that the ICMP attacks draft proposes modifications to 
TCP that reduce the impact of hard errors the same way that blocking 
such ICMPs would.

>>> The rationale for this is included in the ICMP attacks draft. If the 

The outer packet can go along paths that are not necessarily valid for 
the inner packet. There's no reason to enforce filtering on the 
signalling packet's contents in that case.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 May 2006 03:26:03 -0300

At 02:40 19/05/2006, Joe Touch wrote:

>>All BSD-derived and Mentat-derived TCP/IP stacks treat the 
>>so-called "hard errors" as "soft errors".
>>I don't know what Microsoft Windows' stack is derived from. But 
>>they published an advisory on this issue, and their patch is 
>>supposed to treat "hard errors" as "soft errors", too.
>>deployed. Try traceroute. Try ping. They still work. PMTUD works to 
>>a large extent, too.
>
>vulnerable to ICMP attacks, ICMP is blocked. Try pinging hosts 
>behind firewalls or NATs.

In the case of firewalls, ICMP will be filtered when access to the 
actual system is forbidden.

In the case of NAT, the fact that you cannot ping systems usually 
have to do with the fact that there are many systems in the private 
address space, rather than because of "ICMP filtering".

>To the extent that existing implementations violate RFC1122, they 
>do. This isn't the first case of such errors; an RFC was written 
>documenting a number of TCP bugs a while back. ;-)

Reacting to protocol unreachables (as RFC 1122 mandates) means that 
you may reset a connection upon receipt of an ICMP error message that 
might have been elicited by a corrupted segment. Do you think that's correct?

NetBSD, FreeBSD, OpenBSD, Linux, Cisco, Microsoft Windows, Solaris, 
et al, are all wrong, right?

C'mon, Joe.

>>>The document already cites that draft (I can issue a quick update 
>>>to fix the ref to the Feb 06 TCPM version, if that matters).
>I can add the fact that the ICMP attacks draft proposes 
>modifications to TCP that reduce the impact of hard errors the same 
>way that blocking such ICMPs would.

Treating "hard errors" as "soft errors" is an error, but blocking ICMP is not?

C'mon Joe, we have already been over this.

>>>>the counter-measure was just to check the TCP seq number, then, 
>>>>as long as the RFCs are concerned, that would give us the same 
>>>>level of "protection" TCP already has for TCP-based reset attacks 
>>>>(i.e., require the forged packet to be "in window"). Thus, ICMP 
>>>>would still be "the weakest link in the chain".
>>>Filtering on the payload is less useful than filtering on the 
>>>source address; the ICMP packet may be allowed to take a path that 
>>>the source address is not, so it's not necessarily appropriate to 
>>>make filtering decisions on the payload.
>The outer packet can go along paths that are not necessarily valid 
>for the inner packet. There's no reason to enforce filtering on the 

I wrote this for a friend: http://www.gont.com.ar/papers/icmp-errors 
. Again, if we're talking about "performance", that's a different issue.

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 May 2006 09:43:12 -0700

Fernando Gont wrote:
> NetBSD, FreeBSD, OpenBSD, Linux, Cisco, Microsoft Windows, Solaris, et 
> al, are all wrong, right?

Screaming 'fire' in a crowded marketplace is a great way to get vendors 
to jump (off a cliff) - consider the RST stuff, which is NOT needed by 
end hosts, but has made it into virtually every OS as well.

Lemmings are lemmings; they're not always right.

>> I can add the fact that the ICMP attacks draft proposes modifications 
>> to TCP that reduce the impact of hard errors the same way that 
>> blocking such ICMPs would.
> 

Where in the above proposed text is either solution described as an error?

...
> I wrote this for a friend: http://www.gont.com.ar/papers/icmp-errors . 

Your analysis (and some of the work of many throughout this WG, as well) 
tends to assume that everything unexpected is a deliberate attack, and 
thus must be quenched. What if the unexpected is legitimate? What 
capability are you disabling as a result?

Joe

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 May 2006 21:08:43 +0300 (EEST)

On Fri, 19 May 2006, Joe Touch wrote:
> tends to assume that everything unexpected is a deliberate attack, and thus 
> must be quenched. What if the unexpected is legitimate? What capability are 
> you disabling as a result?

Joe,

That's exactly the questions I'd like you to answer regarding your 
suggestion that ignoring ICMP error messages (wrt. IPsec for instance) 
is good thing to do.

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 May 2006 11:26:35 -0700

Pekka Savola wrote:
>> Your analysis (and some of the work of many throughout this WG, as 
>> well) tends to assume that everything unexpected is a deliberate 
>> attack, and thus must be quenched. What if the unexpected is 
>> legitimate? What capability are you disabling as a result?
> 
> Joe,
> 
> is good thing to do

I don't think it is in general. I think that IF you have a security
concern, then you can decide to turn them off FOR YOURSELF (or at your
firewall). But that's no different from blocking certain ports or 
protocols due to security concerns.

I don't want to dictate that sort of behavior for the protocol as a rule 
exactly because it turns off a capability for those not under attack.

Joe

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 19 May 2006 12:33:40 -0700

> protocols due to security concerns.

So, Joe, you agree that at least some systems will simply ignore ICMP,
e.g. because a firewall is programmed to drop all ICMP messages. It
seems then that TCPM should be concerned with the behavior of TCP in
such environments. It would be nice to have ICMP-less alternatives for
the problems that you mention, starting with PMTU discovery, v6/v4 fall
back, etc.

-- Christian Huitema

---

From: Matthew J Zekauskas <[email-masked]>
Date: Fri, 19 May 2006 15:47:01 -0400

pmtud is currently working on an ICMP-less PMTU discovery
method (at least, one where you may ignore ICMP if you choose);
We think the next rev of the method draft will be ready for WGLC.
The next rev should be out within a week or so (fingers crossed).
I invite interested folks to read
<http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-06.txt>
and comment on the PMTUD list ([email-masked]).

--Matt (pmtud co-chair)

--On Friday, May 19, 2006 12:33 PM -0700 Christian Huitema <[email-masked]> wrote

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 May 2006 13:16:06 -0700

> the problems that you mention, starting with PMTU discovery, v6/v4 fall

ICMP-less solutions to PMTUD are being developed already.
v4/v6 failover is an application issue; IMO, opening two connections in 
parallel is sufficient (and ICMP-less).

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 May 2006 02:09:57 -0300

At 15:26 19/05/2006, Joe Touch wrote:

>>suggestion that ignoring ICMP error messages (wrt. IPsec for 
>>instance) is good thing to do
>

"If you have a security concern"?????

Who doesn't have a security concern?

Even if the only thing I did with the Internet was to download 
pirated music and porn, as a user I would still be concerned about my 
downloads being interrupted by some idiot firing ICMP messages.

>I don't want to dictate that sort of behavior for the protocol as a 
>rule exactly because it turns off a capability for those not under attack.

Yea... And the door you have in your house turns off a capability in 
those cases in which there are no thieves out there.

C'mon Joe. There's a point in which what is supposed to be religion 
turns into something else....

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 May 2006 02:09:57 -0300

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 May 2006 02:12:08 -0300

>method (at least, one where you may ignore ICMP if you choose);

This doesn't meant that it will not benefit from ICMP.

(The benefit being a reduction in the convergence time)

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 May 2006 02:12:08 -0300

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 May 2006 22:37:19 -0700

Fernando Gont wrote:
> At 17:16 19/05/2006, Joe Touch wrote:
> 
> I really doubt that implementations will completely get rid of ICMP 
> "frag needed".

Hard to say why they'd keep it if they have a separate, more robust (to 
ICMP blocking) protocol that works sufficiently.

> I bet they are going to implement the mechanism for improving robustness 
> in the case there are no ICMP messages, or that the advertised MTU or 
> something is incorrect.

We'll have to wait to see what happens, but that's what the PMTUD is 
developing.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 May 2006 22:42:20 -0700

Fernando Gont wrote:
> At 13:43 19/05/2006, Joe Touch wrote:
> 
>> Fernando Gont wrote:
>> Screaming 'fire' in a crowded marketplace is a great way to get 
>> vendors to jump (off a cliff)
> 
> Joe, I think you miss the facts, here.
> 
> All BSD-derived and Mentat-derived stacks treat hard errors as soft 
> errors (for connections in any of the synchronized states) since at 
> least 1994.
> 
> There was no scream of "fire".
> 
> As a matter of fact, I met Kirk McKusick and Mike Karels, and asked why, 
> even before the security issues were raised, they had been implementing 
> this for decades. Both of them answered: resetting established 
> connections upon receipt of an ICMP error was simply nonsensical.

Oh, so that's a fine reason. Skip the RFCs (1122 was 5 years prior). 
Just reason it out for yourself.

That may be how implementations get built, but that's not what we're 
here to standardize.

>>  - consider the RST stuff, which is NOT needed by end hosts, but has 
>> made it into virtually every OS as well.
> 
> That stuff is different. If you are concerned about them, use TCP MD5, 
> IPSec, or any similar mechanism.
> 
> There's no (in practice) such a thing for ICMP.

Filtering does the same thing as conversion to soft errors.

> i strongly disagree.
> First, as Section 1.3.2 of RFC 1812 says: "It is best to assume that the 
> network is filled with malevolent entities that will send packets
> designed to have the worst possible effect. This assumption will lead to 
> suitably protective design."

Fine. Then filter all the ICMPs; that's your only protection, and it's 
sufficient. No need to change TCP for that. But once you force the drop 
in the TCP spec, users can't put it back when they actually want the 
service, and when they're in a trusted environment.

If we were to drop everything that might be an attack, we'd never accept 
anything except signed packets.

> Seconds, regarding the capability that "is lost"... in the event you 
> lose any, ICMP is unreliable, anyway.

That's a block we've been around too. IP is unreliable, but if we drop 
them all all the time, we're protected, but also have no functionality.

Do you drop all IP packets too? They might be attacks!

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 May 2006 22:46:52 -0700

Fernando Gont wrote:
> Even if the only thing I did with the Internet was to download pirated 
> music and porn, as a user I would still be concerned about my downloads 
> being interrupted by some idiot firing ICMP messages.

Who is going to bother sending your host ICMP attacks, and why can't 
your system figure that out at the ICMP level (too many ICMPs received, 
so enable a filter to shut them down, in a reactive way)? Why do we need 
to shut off that capability for all TCPs?

> those cases in which there are no thieves out there.

That's why it's not a wall. It opens when I want it to. Defining TCP to 
treat these as soft errors puts up a wall (to the capability); let the 
user do that when they want to, but don't force it.

If an ICMP-level filter isn't enough (and it should be preferable - 
that's the place that you'd know that different protocols were under 
attack simultaneously), maybe you could define an API parameter (ala 
Nagle) that turns these hard errors to soft, sort of a "suspect_ICMP" 
parameter? That way the user could at least turn it back to non-suspect 
if they wanted to, and have a reactive system again.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 May 2006 03:13:00 -0300

At 02:42 20/05/2006, Joe Touch wrote:

>>errors (for connections in any of the synchronized states) since at least 1994.
>>As a matter of fact, I met Kirk McKusick and Mike Karels, and asked 
>>why, even before the security issues were raised, they had been 
>>implementing this for decades. Both of them answered: resetting 
>>established connections upon receipt of an ICMP error was simply nonsensical.
>

So we're here to publish documents that will be completely irrelevant 
to the industry, and that are years behind of the current needs.
Fine. Let's remove the E in IETF. Let's call it ITF

>>>  - consider the RST stuff, which is NOT needed by end hosts, but 
>>> has made it into virtually every OS as well.
>>That stuff is different. If you are concerned about them, use TCP 
>>MD5, IPSec, or any similar mechanism.

No, it doesn't.

If the connection times out, and you filtered the ICMP, you have no 
clue of what went wrong.

>>First, as Section 1.3.2 of RFC 1812 says: "It is best to assume 
>>that the network is filled with malevolent entities that will send packets
>>designed to have the worst possible effect. This assumption will 
>>lead to suitably protective design."
>
>Fine. Then filter all the ICMPs; that's your only protection, and 
>it's sufficient. No need to change TCP for that. But once you force 
>the drop in the TCP spec, users can't put it back when they actually 
>want the service, and when they're in a trusted environment.

That's not true.

You can make it a SHOULD/SHOULD NOT. An operating systems could haFrom [email-masked] Sat May 20 03:43:00 2006
Date: Sat, 20 May 2006 03:13:00 -0300
To: Joe Touch <[email-masked]>
From: Fernando Gont <[email-masked]>
Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-tcp-antispoof-04.txt
Cc: [email-masked]

At 02:42 20/05/2006, Joe Touch wrote:

>>errors (for connections in any of the synchronized states) since at least 1994.
>>As a matter of fact, I met Kirk McKusick and Mike Karels, and asked 
>>why, even before the security issues were raised, they had been 
>>implementing this for decades. Both of them answered: resetting 
>>established connections upon receipt of an ICMP error was simply nonsensical.
>

So we're here to publish documents that will be completely irrelevant 
to the industry, and that are years behind of the current needs.
Fine. Let's remove the E in IETF. Let's call it ITF

>>>  - consider the RST stuff, which is NOT needed by end hosts, but 
>>> has made it into virtually every OS as well.
>>That stuff is different. If you are concerned about them, use TCP 
>>MD5, IPSec, or any similar mechanism.

No, it doesn't.

If the connection times out, and you filtered the ICMP, you have no 
clue of what went wrong.

>>First, as Section 1.3.2 of RFC 1812 says: "It is best to assume 
>>that the network is filled with malevolent entities that will send packets
>>designed to have the worst possible effect. This assumption will 
>>lead to suitably protective design."
>
>Fine. Then filter all the ICMPs; that's your only protection, and 
>it's sufficient. No need to change TCP for that. But once you force 
>the drop in the TCP spec, users can't put it back when they actually 
>want the service, and when they're in a trusted environment.

That's not true.

You can make it a SHOULD/SHOULD NOT. An operating systems could have 
a sysctl for it.
It could be net.inet.icmp.hackme, and current ICMP processing would 
be enabled by setting the variable to 1.

>>Seconds, regarding the capability that "is lost"... in the event 
>>you lose any, ICMP is unreliable, anyway.
>
>That's a block we've been around too. IP is unreliable, but if we 
>drop them all all the time, we're protected, but also have no functionality.
>

Joe,

While I respect your opinion, the WG has already got to consensus on 
these issues.

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 May 2006 03:18:27 -0300

At 02:46 20/05/2006, Joe Touch wrote:

>>pirated music and porn, as a user I would still be concerned about 
>>my downloads being interrupted by some idiot firing ICMP messages.
>
>your system figure that out at the ICMP level (too many ICMPs 
>received, so enable a filter to shut them down, in a reactive way)?

You only need one packet to reset a connection.

>Why do we need to shut off that capability for all TCPs?

It's already shut off. I can only think that you hacked the kernel of 
your OS to implement RFC1222-processing of ICMP messages. ;-)

>>>I don't want to dictate that sort of behavior for the protocol as 
>>>a rule exactly because it turns off a capability for those not under attack.
>>Yea... And the door you have in your house turns off a capability 
>>in those cases in which there are no thieves out there.
>
>That's why it's not a wall. It opens when I want it to. Defining TCP 
>to treat these as soft errors puts up a wall (to the capability); ve 
a sysctl for it.

Joe,

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 May 2006 03:18:27 -0300

>to treat these as soft errors puts up a wall (to the capability); 
>let the user do that when they want to, but don't force it.

No, you put a wall if you filtr ICMP in the network.

If you implement that in TCP, then it's up to the user to enable it 
explicitly, and screw his life up himself.

>Nagle) that turns these hard errors to soft, sort of a 
>"suspect_ICMP" parameter? That way the user could at least turn it 
>back to non-suspect if they wanted to, and have a reactive system again.

Joe,

Again: do you think that resetting a TCP conenction in response to, 
say, an ICMP protocol unreachable is the proper thing to do?

If not, I don't understand what you're arguing.

Kindest regards,

>let the user do that when they want to, but don't force it.

No, you put a wall if you filtr ICMP in the network.

If you implement that in TCP, then it's up to the user to enable it 
explicitly, and screw his life up himself.

>Nagle) that turns these hard errors to soft, sort of a 
>"suspect_ICMP" parameter? That way the user could at least turn it 
>back to non-suspect if they wanted to, and have a reactive system again.

Joe,

Again: do you think that resetting a TCP conenction in response to, 
say, an ICMP protocol unreachable is the proper thing to do?

If not, I don't understand what you're arguing.

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 May 2006 03:02:50 -0300

At 02:37 20/05/2006, Joe Touch wrote:

>Hard to say why they'd keep it if they have a separate, more robust 
>(to ICMP blocking) protocol that works sufficiently.

There's the issue of "convergence time". For interactive 
applications, such as the web, it is important.

More than one free operating system opposed to get rid of ICMP "frag 
needed" for PMTUD, for the above reason.

This does not mean that they wouldn't implement PLPMTUD, but that 
they wouldn't implement it without the aid of ICMP.

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Sat, 20 May 2006 07:34:41 -0700

Fernando Gont wrote:
...
> Again: do you think that resetting a TCP conenction in response to, say, 
> an ICMP protocol unreachable is the proper thing to do?

Yes. It means the protocol is unreachable. If you don't trust ICMP, then 
block it altogether.

Your other message want PMTUD to be reactive, so you want ICMP signals 
there. Why would you allow attackers to alter your PMTU, when you are so 
worried here? The same net effect results - throughput can be set to 
effectively zero in either case.

IMO, *if* you don't trust ICMP, that's a transport-wide decision. I 
don't see a reason to discriminate within TCP.

(and yes, if it's *broken* w.r.t. the specs, we ought to recommend 
fixing it; in the IETF, we're supposed to do what we thing needs to be 
done first and let the implementations follow, not the other way around. 
It's rough consensus and running code, not de-facto rubberstamps).

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sun, 21 May 2006 00:06:12 -0300

At 11:34 20/05/2006, Joe Touch wrote:

>Yes. It means the protocol is unreachable.

It may mean that the protocol is unreachable.... or that some 
corrupted packet elicited the ICMP error message in question. ;-)

And, btw, you were able to establish a connection, and now TCP is 
gone? Did you give root access to your kids, or what? (and they have 
a loadable-module TCP, which they load and unload all the time).

What policy makes the network more robust? What policy makes TCP more robust?

Shouldn't the Internet be robust?

>If you don't trust ICMP, then block it altogether.

Engineering is usually a trade-off, rather than a white or black thing.

I'm interested in having a robust network, while still knowing the 
cause of problems when something goes on.
Namely, if my connections time out, I'd like to know why.

This is sort of what D. Clark said about twenty years ago, btw.

>Your other message want PMTUD to be reactive, so you want ICMP 
>signals there. Why would you allow attackers to alter your PMTU, 
>when you are so worried here? The same net effect results - 
>throughput can be set to effectively zero in either case.

In order for an attacker to defeat the mechanism discussed in the 
ICMP attacks draft, he has to be a "man in the middle". At that 
point, he wouldn't bother to set a low MTU.

Why I'd like PMTU to be reactive?
Because I wouldn't to be in the position to explain the user 
community while they now have to wait to get the web page they want to get.

>don't see a reason to discriminate within TCP.

The checks are transport-protocol specific.

>fixing it; in the IETF, we're supposed to do what we thing needs to 
>be done first and let the implementations follow, not the other way 
>around. It's rough consensus and running code, not de-facto rubberstamps).

If it takes us years to change the specs, I'm afraid it will be us 
following the implementations.

And, no, I don't consider the ICMP attacks rubberstamps. For 
instance, I'd say all the people listed in the acknowledgements 
(other than you, if you want) agreed that this is the right thing to do.

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Sun, 21 May 2006 11:38:25 -0700

Fernando Gont wrote:
> It may mean that the protocol is unreachable.... or that some corrupted 
> packet elicited the ICMP error message in question. ;-)
> 
> And, btw, you were able to establish a connection, and now TCP is gone? 
> Did you give root access to your kids, or what? (and they have a 
> loadable-module TCP, which they load and unload all the time).

Maybe you ran an OS that installed updates as you went automatically. 
Maybe the node is a laptop that's been shut. There are many reasons for 
a legitimate message.

> Shouldn't the Internet be robust?

Yes. Especially to the whims of people who think that every message they 
don't _expect_ means an attack ;-)

> Engineering is usually a trade-off, rather than a white or black thing.

Agreed. Which is also a reason not to burn this decision into the 
transport protocol. A separate filter can make the decisions you're 
suggesting just fine.

> I'm interested in having a robust network, while still knowing the cause 
> of problems when something goes on.

Goes to intent. Sometimes you can't. Sometimes all you know is that they 
went down.

...
>> there. Why would you allow attackers to alter your PMTU, when you are 
>> so worried here? The same net effect results - throughput can be set 
>> to effectively zero in either case.
> 
> In order for an attacker to defeat the mechanism discussed in the ICMP 
> attacks draft, he has to be a "man in the middle". At that point, he 
> wouldn't bother to set a low MTU.

Sure he would - to avoid your thinking he was there. To make you think 
you weren't under a 'real' attack.

> Because I wouldn't to be in the position to explain the user community 
> while they now have to wait to get the web page they want to get.

So here you want to know what's going on, so the ICMP needs to get 
through. But in the case of TCP, you want to know what's going on, but 
that means blocking ICMP. This all goes to whether you expect the 
message under normal operations, not whether it's reasonable in a 
network that isn't under attack.

> The checks are transport-protocol specific.

How do they differ for TCP vs. SCTP and DCCP?

>> done first and let the implementations follow, not the other way 

You're not answering the question. The point is that the implementations 
don't weigh into the decision on how to proceed here.

> And, no, I don't consider the ICMP attacks rubberstamps. For instance, 
> I'd say all the people listed in the acknowledgements (other than you, 
> if you want) agreed that this is the right thing to do.

IETF process is by "rough consensus", which does not mean unanimous 
approval nor does it mean approval by those who contributed to the 
document. There's no need to state that there.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Mon, 22 May 2006 07:58:32 +0300 (EEST)

On Sun, 21 May 2006, Joe Touch wrote:
[Joe quoting Fernando]
> don't weigh into the decision on how to proceed here.

Joe, I think the majority of the IETF has a very different view of 
what 'running code' implies in the slogan 'rough consensus and running 
code'.

There _is_ an AND there, but (IMHO) that's relevant only if the 
running code and rough consensus were at significant odds with each 
other.  I don't think that's the case, as it happens there was rough 
consensus to work on these docs, and this discussion isn't 
contributing anything to the drafts; we've been through this before 
and opted to go for it.

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 May 2006 07:14:30 -0700

Pekka Savola wrote:
>> You're not answering the question. The point is that the 
>> implementations don't weigh into the decision on how to proceed here.
> 
> Joe, I think the majority of the IETF has a very different view of what 
> 'running code' implies in the slogan 'rough consensus and running code'.

It means proof of a protocol idea that gets it from PS to DS to S. It 
doesn't mean a vote in the process to decide whether to move forward to 
PS with an idea.

Which is why it has no bearing at this phase in the process, IMO.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 May 2006 02:03:35 -0300

>transport protocol. A separate filter can make the decisions you're 

You can enable this explicitly if you want. Although nobody would do 
it. Most systems have been running with the proposed behaviour in 
place, with no way to enable it.

>Goes to intent. Sometimes you can't. Sometimes all you know is that 
>they went down.

Exactly. That's the idea of changing the reaction, so that you keep 
the hint, without being vulnerable to attack.

>Sure he would - to avoid your thinking he was there. To make you 
>think you weren't under a 'real' attack.

If you are a MIM, you can fool the ICMP-less PMTUD, as you can drop 
packets.  ;-)

>>>fixing it; in the IETF, we're supposed to do what we thing needs 
>>>to be done first and let the implementations follow, not the other 
>>>way around. It's rough consensus and running code, not de-facto rubberstamps).

As pointed out by Pekka, both the rough consensus and the 
implementations agree.

(As a side note, FWIW, the stuff in RFC1122 about {netowork, subnet, 
0} broadcast addresses seem to have been driven by implementations.)

Kindest regards,