Re: What ICMP packets does state RELATED allow?

[Ramin Alidousti <ramin@cannon.eng.us.uu.net>]

On Thu, Jun 06, 2002 at 06:59:42PM -0400, Joe Patterson wrote:

> > You're absolutely right. An ICMP redirect is sent from one interface
> > to another interface on the _same_ subnet. In some ways it should be
> > seen as something like an ARP which has a layer 2 significance. However,
> > proxying ARP make sense but proxying (or forwarding in general) of an
> > ICMP redirect does not make sense at all. Whether it could be seen as
> > RELATED or not is sort of philosophical matter as ICMP redirect is meant
> > to _notify_ a forwarding entity of the existence of a better next-hop on
> > the _same_ subnet.
> 
> Actually, no, it's not.  It is meant to notify a *host* that is *not* a
> forwarding entity (or at least is not acting as a forwarding entity for the

Picture this:

A is an internal host. B is the masquerading gateway and C and D are the
upstream routers at the ISP's edge, sitting on the same subnet. When the
ISP sold this service, as usual, they sold it as a "one single IP host".
In the initial configuration, the ISP, which at that time had only C at
the edge, instructed the users to use C as their default gateway, but
knowing that at some point in the future they might transition this role
to a more powerful/suitable router they relied on ICMP redirect as opposed
to contacting every single customer by phone or mail about this change.

Yes, I know that these days DHCP takes care of this case but I just
wanted to give an example as of how it can be helpful.

> purposes of the packet that caused the redirect)  The assumption is that two
> forwarding entities will be exchanging routing information at a higher level

Not necessarily. There are lots of static routes out there...

> routing protocol, but that a host may not be running a routing process and
> may only have a default route.

Again, not necessarily. You could run a routing process and only receive
a default route...

> This is a subtle distinction.  Note that a
> gateway has no reliable method of determining the ip address of the last hop
> a packet came from.

True. But see the example above.

> It knows the mac address, but not the IP.  Therefore,
> there's no reliable way for one forwarding entity that recieves a packet
> with a non-local source address to know the ip address of the forwarding
> entity that it should send a redirect to if it were to desire to send such a
> redirect.  (that's an ugly sentence...)  Thus, a forwarding entity which
> might wish to send such a redirect has two choices.  It could send the
> redirect to the original source address, knowing full well that that
> original source has no way to influence the routing decision made by the
> last-hop router, or it can do what the rfc's say and ignore the situation.
> 
> > So, is this kind of thing RELATED? Yes, in the sense
> > that it is caused by the forwarding of _that_ packet and no, in the sense
> > that the same redirect could get triggered by lots of other non related
> > conn's and besides ignoring these redirects would not harm the
> > communication
> > at all.
> 
> although, when it comes right down to it, it's probably related because it's
> one of those icmp packet types that contains an ip header in the data
> portion, so it *can* be related.

Yes, but does this mean that only because it's related B should forward
this ICMP to A? Definitely not. We need to have some intelligence as to
how to interprete the related packets and what to do with them.

> And, if netfilter is running on a host and
> that host might generate traffic and send it through a non-optimal router,
> it could be usefull to accept it.  However, I can definitely see an
> opportunity for abuse in some cases,

When ICMP was being born there was lesser attention about the security
implications (just think about SNMPv1, telnet...). The network was being
considered a friend and on top of this friendly network, one was thinking
about the improvements by introducing the "control messages" to help the
IP which only has "routing" functionality.

> and the worst thing that can happen by
> completely ignoring (or dropping)  redirects is sub-optimal routing.  So
> it's probably a good idea to just drop the whole thing.

Nod.

Ramin

> -Joe