What ICMP packets does state RELATED allow?

What ICMP packets does state RELATED allow?

[Nathan Cassano]

Hi NetFilter Gurus,
	I have heard that ip_conntrack will allow ICMP packets pass that
are related to an existing connection. My question is what specific
related ICMP packets does conntrack allow for a given connection? Does
it allow Source Quench (--icmp-type 4) or Redirects (--icmp-type 5)? 

Re: What ICMP packets does state RELATED allow?

[Nick Drage]

On Wed, Jun 05, 2002 at 03:07:20PM -0700, Nathan Cassano wrote:
> 
> Hi NetFilter Gurus,
> 	I have heard that ip_conntrack will allow ICMP packets pass that
> are related to an existing connection. My question is what specific
> related ICMP packets does conntrack allow for a given connection? Does
> it allow Source Quench (--icmp-type 4) or Redirects (--icmp-type 5)? 

See Joe's rather excellent answer to my previous question along these lines:

http://lists.samba.org/pipermail/netfilter/2002-May/023188.html

-- 
FunkyJesus System Administration Team

RE: What ICMP packets does state RELATED allow?

[Joe Patterson]

although, in the case of the question that Nathan asked, my answer didn't
address those particular packet types.  My suspicion is that source quench
is treated as related, because it should be.  Redirects are somewhat more
tricky.  They *should* never be routed, because routing them makes no sense.
I think that they often are anyway, since pure routers don't want to spend
the effort to care.  I would posit that in general, a firewall, which by its
nature *can* spend the effort to care, should never forward them.  If I'm
reading the rfc's correctly, a gateway should not send an icmp redirect to a
source address that is not on a directly attached network.  Furthermore, a
host that recieves a redirect from *either* 1) a gateway that is not the
gateway that it would route the packet that caused the redirect to in the
first place or 2) a gateway that is not on a directly connected network,
then that host should ignore the redirect entirely.

So, the answer is: Source quench, probably.  Redirects: most likely not.  I
have not, however, gone through the code to see if this is indeed the case.
Nor have I tried it. (It's somewhat difficult to test, as a properly
operating gateway wouldn't send such a beast.  Perhaps with some mucking
about with netmasks it could be done....)

-Joe

> -----Original Message-----
> From: netfilter-admin@lists.samba.org
> [mailto:netfilter-admin@lists.samba.org]On Behalf Of Nick Drage
> Sent: Wednesday, June 05, 2002 6:30 PM
> To: netfilter@lists.samba.org
> Subject: Re: What ICMP packets does state RELATED allow?
>
>
> On Wed, Jun 05, 2002 at 03:07:20PM -0700, Nathan Cassano wrote:
> >
> > Hi NetFilter Gurus,
> > 	I have heard that ip_conntrack will allow ICMP packets pass that
> > are related to an existing connection. My question is what specific
> > related ICMP packets does conntrack allow for a given connection? Does
> > it allow Source Quench (--icmp-type 4) or Redirects (--icmp-type 5)?
>
> See Joe's rather excellent answer to my previous question along
> these lines:
>
> http://lists.samba.org/pipermail/netfilter/2002-May/023188.html
>
> --
> FunkyJesus System Administration Team
>
>
>
>

RE: What ICMP packets does state RELATED allow?

[Jozsef Kadlecsik]

On Wed, 5 Jun 2002, Joe Patterson wrote:

> although, in the case of the question that Nathan asked, my answer didn't
> address those particular packet types.  My suspicion is that source quench
> is treated as related, because it should be.  Redirects are somewhat more
> tricky.  They *should* never be routed, because routing them makes no sense.
> I think that they often are anyway, since pure routers don't want to spend
> the effort to care.  I would posit that in general, a firewall, which by its
> nature *can* spend the effort to care, should never forward them.  If I'm
> reading the rfc's correctly, a gateway should not send an icmp redirect to a
> source address that is not on a directly attached network.  Furthermore, a
> host that recieves a redirect from *either* 1) a gateway that is not the
> gateway that it would route the packet that caused the redirect to in the
> first place or 2) a gateway that is not on a directly connected network,
> then that host should ignore the redirect entirely.

According to the source code, the following ICMP messages are treated as
RELATED (if the payload matches one of the already existing connection):

destination-ureachable
source-quench
time-exceeded
paremeterproblem
redirect

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

RE: What ICMP packets does state RELATED allow?

[Joe Patterson]

That's interesting...  I guess it could make sense... sort of...

but, to be really obnoxious about it, I would think it would make sense to
have rules such as:

for IF in `ifconfig | cut -d " " -f 1 | grep -v ^$`; do
	$IPT -A INPUT -p icmp --icmp-type 5 -m state --state RELATED -i $IF -s `ip
addr ls dev $IF | grep inet | cut -d " " -f 6` -j ACCEPT
done

and

$IPT -A FORWARD -p icmp --icmp-type 5 -j DROP

on the basis of my belief that you should never ever have a redirect
crossing a router, but you *may* want to accept redirects from local
gateways...

Any thoughts?

-Joe

> -----Original Message-----
> From: Jozsef Kadlecsik [mailto:kadlec@blackhole.kfki.hu]
> Sent: Thursday, June 06, 2002 7:51 AM
> To: Joe Patterson
> Cc: Nick Drage; netfilter@lists.samba.org
> Subject: RE: What ICMP packets does state RELATED allow?
>
>
> On Wed, 5 Jun 2002, Joe Patterson wrote:
>
> > although, in the case of the question that Nathan asked, my
> answer didn't
> > address those particular packet types.  My suspicion is that
> source quench
> > is treated as related, because it should be.  Redirects are
> somewhat more
> > tricky.  They *should* never be routed, because routing them
> makes no sense.
> > I think that they often are anyway, since pure routers don't
> want to spend
> > the effort to care.  I would posit that in general, a firewall,
> which by its
> > nature *can* spend the effort to care, should never forward
> them.  If I'm
> > reading the rfc's correctly, a gateway should not send an icmp
> redirect to a
> > source address that is not on a directly attached network.
> Furthermore, a
> > host that recieves a redirect from *either* 1) a gateway that is not the
> > gateway that it would route the packet that caused the redirect
> to in the
> > first place or 2) a gateway that is not on a directly connected network,
> > then that host should ignore the redirect entirely.
>
> According to the source code, the following ICMP messages are treated as
> RELATED (if the payload matches one of the already existing connection):
>
> destination-ureachable
> source-quench
> time-exceeded
> paremeterproblem
> redirect
>
> Regards,
> Jozsef
> -
> E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
> WWW-Home: http://www.kfki.hu/~kadlec
> Address : KFKI Research Institute for Particle and Nuclear Physics
>           H-1525 Budapest 114, POB. 49, Hungary
>
>
>

Re: What ICMP packets does state RELATED allow?

[Ramin Alidousti]

On Thu, Jun 06, 2002 at 09:55:09AM -0400, Joe Patterson wrote:

> That's interesting...  I guess it could make sense... sort of...
> 
> but, to be really obnoxious about it, I would think it would make sense to
> have rules such as:
> 
> for IF in `ifconfig | cut -d " " -f 1 | grep -v ^$`; do
> 	$IPT -A INPUT -p icmp --icmp-type 5 -m state --state RELATED -i $IF -s `ip
> addr ls dev $IF | grep inet | cut -d " " -f 6` -j ACCEPT
> done
> 
> and
> 
> $IPT -A FORWARD -p icmp --icmp-type 5 -j DROP
> 
> on the basis of my belief that you should never ever have a redirect
> crossing a router, but you *may* want to accept redirects from local
> gateways...
> 
> Any thoughts?

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

Ramin

> 
> -Joe

RE: What ICMP packets does state RELATED allow?

[Joe Patterson]

> 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
purposes of the packet that caused the redirect)  The assumption is that two
forwarding entities will be exchanging routing information at a higher level
routing protocol, but that a host may not be running a routing process and
may only have 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.  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.  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, 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.

-Joe

>
> Ramin
>
> >
> > -Joe
>
>
>

Re: What ICMP packets does state RELATED allow?

[Ramin Alidousti]

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

RE: What ICMP packets does state RELATED allow?

[Jozsef Kadlecsik]

On Thu, 6 Jun 2002, Joe Patterson wrote:

> That's interesting...  I guess it could make sense... sort of...
>
> but, to be really obnoxious about it, I would think it would make sense to
> have rules such as:
>
> for IF in `ifconfig | cut -d " " -f 1 | grep -v ^$`; do
> 	$IPT -A INPUT -p icmp --icmp-type 5 -m state --state RELATED -i $IF -s `ip
> addr ls dev $IF | grep inet | cut -d " " -f 6` -j ACCEPT
> done
>
> and
>
> $IPT -A FORWARD -p icmp --icmp-type 5 -j DROP
>
> on the basis of my belief that you should never ever have a redirect
> crossing a router, but you *may* want to accept redirects from local
> gateways...

conntrack is responsible to keep track of the connections as perfectly
(and with as little overhead) as possible. At the filter stage one can
filter out the unwanted packets exactly as you suggested.

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary