Re: ICMP pokes holes in firewalls...

From: Darren Reed (avalon_at_caligula.anu.edu.au)
Date: 09/27/03

  • Next message: Q?=Ilya TeterinQ=20?=: "Re: base64"
    To: daniel@benzedrine.cx (Daniel Hartmeier)
    Date: Sat, 27 Sep 2003 19:21:36 +1000 (Australia/ACT)
    
    

    In some mail from Daniel Hartmeier, sie said:
    >
    > On Fri, Sep 26, 2003 at 10:13:56AM +1000, Darren Reed wrote:
    >
    > > There's also a general problem here, that needs attention and that
    > > is you really shouldn't allow more ICMP error packets through than
    > > you see normal connection packets. ie. one UDP packet out should
    > > not allow more than one ICMP error message back in.
    >
    > Technically, a single packet may cause multiple legitimate ICMP errors.
    > As per RFC 792, an ICMP redirect does not imply that the packet was dropped
    > (quite the contrary) and ICMP source quench may be sent without dropping
    > the packet. Hence, further hops may send further ICMP errors for the
    > same packet.

    Only if a sending host is misbehaving will you ever get more than 1
    redirect per packet flow as routers beyond the first hop should not
    be sending redirects that make it back to the origin.

    So what if a source quench gets dropped ? In situations where it's
    likely to be sent, it getting dropped is more likely than normal.

    And since you're quoting RFC's...

    I have to wonder whether or not you read the OpenBSD source code before
    saying this or maybe the OpenBSD source code is missing this comment
    that I can see in NetBSD's IP code:

                     * a router should not generate ICMP_SOURCEQUENCH as
                     * required in RFC1812 Requirements for IP Version 4 Routers.
                     * source quench could be a big problem under DoS attacks,
                     * or if the underlying interface is rate-limited.

    RFC 1812, section 4.3.3.3 (page 57) discusses this.

    > Rate limiting the ICMP errors with a strict 1:1 ratio would break
    > traceroute through a gateway that forwards back to the same network, or
    > one operating near its capacity limit, for instance.

    It won't break any version of traceroute that I'm aware of.

    > So, what do we gain by rate limiting the ICMP errors?

    If I send 1 UDP packet out, how many ICMP errors should I ever
    receive that match it ? 1 ? 10 ? 100 ? Up to the ttl value
    of the packet as it passed through ? What does your experience
    tell you? What do you consider "normal" vs what should be
    considered "acceptable" ?

    On the other end of this, have *you* had any experience with rate
    limited ICMP error message generation ? If you did, did traceroute
    not work because it was present ?

    Darren


  • Next message: Q?=Ilya TeterinQ=20?=: "Re: base64"