Re: [tcpm] ICMP attacks draft

Joe Touch <touch@ISI.EDU> Thu, 20 July 2006 05:01 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Qen-00051J-I7; Thu, 20 Jul 2006 01:01:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Qem-00051D-GZ for tcpm@ietf.org; Thu, 20 Jul 2006 01:01:04 -0400
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Qel-00087K-2o for tcpm@ietf.org; Thu, 20 Jul 2006 01:01:04 -0400
Received: from [192.168.1.42] (pool-71-106-102-77.lsanca.dsl-w.verizon.net [71.106.102.77]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6K50BH16643; Wed, 19 Jul 2006 22:00:11 -0700 (PDT)
Message-ID: <44BF0DD1.4000509@isi.edu>
Date: Wed, 19 Jul 2006 22:00:01 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] ICMP attacks draft
References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> <44BB1882.6030904@isi.edu> <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> <44BCE4FA.1050602@isi.edu> <7.0.1.0.0.20060718160252.066880d8@gont.com.ar> <44BD514C.2090704@isi.edu> <7.0.1.0.0.20060718192327.0427b290@gont.com.ar> <44BD7441.9050206@isi.edu> <7.0.1.0.0.20060719031923.04a637f0@gont.com.ar> <44BE4C27.1010600@isi.edu> <7.0.1.0.0.20060719200945.0625ec08@gont.com.ar>
In-Reply-To: <7.0.1.0.0.20060719200945.0625ec08@gont.com.ar>
X-Enigmail-Version: 0.94.0.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Cc: tcpm@ietf.org, "Anantha Ramaiah (ananth)" <ananth@cisco.com>
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0621059897=="
Errors-To: tcpm-bounces@ietf.org


Fernando Gont wrote:
> At 12:13 19/07/2006, Joe Touch wrote:
> 
>> > I understand what you mean. However, the message codes to which we are
>> > changing from hard to soft errors (protocol unreachable and port
>> > unreachable) are not the ones that would reflect a routing change.
>>
>> Sorry - long time since I got into this level of detail. We're talking
>> about dest unreachable codes 2-4, i.e.:
>>         2 protocol
>>         3 port
>>         4 frag needed and DF set
>>
>> Changing these from hard to soft AFTER connection establishment means:
>>
>>         - slower reaction (if at all?) to host reconfiguration
>>                 2,3 - dynamic reloading of protocol module fails
> 
> Agreed in the case of protocol unreachable. But for port unreachable,
> the protocol module is there.

That depends on what protocol; port unreachable would happen for the
application protocol failure.

>>                 3 - unexpected application termination (?)
>>                         although TCP can send a RST in this case,
>>                         ICMP should also generate port unreachable (?)
> 
> What I recall is that the idea of making TCP abort connections upon
> receipt of port unreach had to do with accomodating implementation that
> rejected connection requests with ICMP port unreachables, rather than
> with RSTs.
> 
> In the case of TCP, only RSTs should be sent. As a matter of fact,
> sending both RSTs and port unreachables could be used by an attacker as
> a bandwidth amplifier.

1122 allows both. It makes specific statements that the RST isn't a
replacement for the ICMP. It might be OK to say that if a RST is
generated then the ICMP shouldn't be, but that'd be in an 1122
'host-wide' document, not in an ICMP document (which shouldn't discuss
snooping the TCP segments).

You're implying that ICMP port unreachable should never be sent when
there is a functioning TCP (i.e., protocol unreachable is OK, but never
port) - and THAT is your rationale for treating them as soft errors. If
that's the case, then they should be silently dropped, and you are
REALLY changing 1122.

>> Reloading protocols isn't unheard of (netgraph, etc.). Failure of that
>> protocol has many consequences, and at some level nonresponsiveness is
>> its own signal, but softening these signals basically means you are
>> assuming that protocols don't change once a connection is up. That's a
>> NEW assumption and should be noted.
> 
> Agreed. In this case, we are limiting the discussion to TCP, though.

I was talking about TCP - e.g., loading a new implementation of TCP.

>>         - slower/no reaction to path change
>>                 4 - change in path MTU
> 
> IMHO, this would kill robustness. In TCP, you implement PMTUD, or don't
> set the DF bit.

Or you expect the connection to go down because of the specified
behavior of ICMP. That might allow a host to try a different path,
different endpoint, etc. more quickly.

>> As to the case where ICMP Frag needed should generate a hard error,
>> consider:
>>         - simple TCP stack that lacks PMTUD
>>         - an intermediate device sets the DF bit
>>
>> I saw that case a few years ago. Changing hard to soft changes reaction
>> to that event
> 
> Well, that seems non-compliant, anyway.

Based on what? I could find nothing that prohibits a node from setting
the DF bit - that could occur when fragmentation is not desired (fate
sharing over wireless links, e.g.) even though the end system can
support it.

> Also, for robustness-sake, you
> probably don't have many choices other than keep retransmitting.

That's what happens due to your proposed modification. If these errors
are still hard, then the connection goes down and you can recover at the
application layer by trying a different endpoint, different parameters,
etc. - something that might change the path properties.

Joe

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm