Re: [tcpm] ICMP attacks draft

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.

>                 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.

>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.

>         - 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.

>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. Also, for robustness-sake, 
you probably don't have many choices other than keep retransmitting.

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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