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

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

Folks,

My point on section 4 ("ICMP") of the document is that only one of 
all the counter-measures of the ICMP attacks draft is discussed.

Being that the ICMP attacks draft is a WG item, that the WG got rough 
consensus on, I don't think all the other (and main!) 
counter-measures should be excluded from the discussion.

If anything, there should be consensus not to discuss them in the 
antispoof draft.

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: Joe Touch <[email-masked]>
Date: Tue, 23 May 2006 21:04:48 -0700

Fernando Gont wrote:
> Folks,
> 
> My point on section 4 ("ICMP") of the document is that only one of all 
> the counter-measures of the ICMP attacks draft is discussed.

I've already noted that I would add a comment that there are other 
measures under development.

> consensus on, I don't think all the other (and main!) counter-measures 
> should be excluded from the discussion.

The point of the document is not the countermeasures; it is that ICMP is 
not addressed by the techniques discussed, and that the primary (and 
still primary) method to deal with ICMP attacks is to drop all ICMP 
packets. I stand by that conclusion, and have heard nothing to refute it.

> If anything, there should be consensus not to discuss them in the 

There was already consensus that they were added. I'd be glad to remove 
the section if there is consensus; IMO, it's premature to recommend in 
this document something that the WG has not agreed to recommend in 
another (documenting existing practice != recommend).

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 May 2006 08:02:48 -0300

>measures under development.

Good.

>>Being that the ICMP attacks draft is a WG item, that the WG got 
>>rough consensus on, I don't think all the other (and main!) 
>The point of the document is not the countermeasures; it is that 
>ICMP is not addressed by the techniques discussed, and that the 
>primary (and still primary) method to deal with ICMP attacks is to 
>drop all ICMP packets. I stand by that conclusion, and have heard 
>nothing to refute it.

I disagree with that of the primary counter-measure for ICMP is to 
drop all ICMP packets. First, the tests I have made with tools to 
perform the attacks described in the ICMP attacks draft made it clear 
that there's no such a big deployment of ICMP messages (actually, as 
I say in some other e-mail, ICMP messages get dropped at NATs because 
there's no state information for them. Just that).

I propose to mention at tcpsecure (etc) do not address ICMP attacks 
(that include blind connection-reset attacks), and state that the WG 
is working on counter-measures, and that many TCP/IP stacks already 
implement them.

That doesn't we are "recommending" them. Just stating facts.

The deployment of systems implementing the "hard errors -> soft 
errors" behaviour outnumbers (by far) the deployment of systems 
blocking ICMP error messages for which there is state information.

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 May 2006 09:56:50 -0700

Fernando Gont wrote:
...
>> The point of the document is not the countermeasures; it is that ICMP
>> is not addressed by the techniques discussed, and that the primary
>> (and still primary) method to deal with ICMP attacks is to drop all
>> ICMP packets. I stand by that conclusion, and have heard nothing to
>> refute it.
> 
> I disagree with that of the primary counter-measure for ICMP is to drop
> all ICMP packets. First, the tests I have made with tools to perform the
> attacks described in the ICMP attacks draft made it clear that there's
> no such a big deployment of ICMP messages (actually, as I say in some
> other e-mail, ICMP messages get dropped at NATs because there's no state
> information for them. Just that).

See RFC4301; that's the primary network security architecture for the
Internet, and it discusses exactly this issue. It does suggest that a
mechanism is required where ICMPs are *all* dropped, but requires that
it be configurable.

Interestingly, it requires that the capability be configurable, and
makes _no_ recommendation to default it to ON.

However, firewalls at enterprises dropping all ICMPs is fairly well
known (at least AFAICT - is there really disagreement about this? I can
dig into NANOG to get info, but it seems less useful given 4301 doesn't
provide cites on this point).

> (that include blind connection-reset attacks), and state that the WG is
> working on counter-measures, and that many TCP/IP stacks already
> implement them.

That'd be fine (modulo "countermeasures +for some cases+"), provided it
comes with the additional caveat that the existing way to protect
against ICMP attacks (which is already implemented as well) is to filter
all ICMPs (ref 4301).

> That doesn't we are "recommending" them. Just stating facts.

Agreed, in both cases (yours and 4301's).

> The deployment of systems implementing the "hard errors -> soft errors"
> behaviour outnumbers (by far) the deployment of systems blocking ICMP
> error messages for which there is state information.

This isn't a popularity contest; it's about specs, and
		 792 + 1122 + 4301 > I-D

(again, just stating facts ;-)

Joe