ipfilter, return-icmp and RFC1122

[Petar Bogdanovic]

Hi,

I recently noticed that ipfilter with `block return-icmp' is returning
ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
broadcast:

130.3.3.3 ---------[***@130.3.3.255]--------> 130.3.3.4
130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4


This seems wrong, considering RFC1122, page 39:

An ICMP error message MUST NOT be sent as the result of
receiving:

* an ICMP error message, or

* a datagram destined to an IP broadcast or IP multicast
address, or

* a datagram sent as a link-layer broadcast, or

* a non-initial fragment, or

* a datagram whose source address does not define a single
host -- e.g., a zero address, a loopback address, a
broadcast address, a multicast address, or a Class E
address.


Is this desired behaviour?

My ipf.conf:

pass in quick on lo0 all
pass out quick on lo0 all

block in quick from 192.168.0.0/16 to any
block in quick from 172.16.0.0/12 to any
block in quick from 10.0.0.0/8 to any
block in quick from 127.0.0.0/8 to any
block in quick from 0.0.0.0/8 to any
block in quick from 169.254.0.0/16 to any
block in quick from 192.0.2.0/24 to any
block in quick from 204.152.64.0/23 to any
block in quick from 224.0.0.0/3 to any

block out log first level auth.info quick from any to 192.168.0.0/16
block out log first level auth.info quick from any to 172.16.0.0/12
block out log first level auth.info quick from any to 10.0.0.0/8
block out log first level auth.info quick from any to 127.0.0.0/8
block out log first level auth.info quick from any to 0.0.0.0/8
block out log first level auth.info quick from any to 169.254.0.0/16
block out log first level auth.info quick from any to 192.0.2.0/24
block out log first level auth.info quick from any to 204.152.64.0/23
block out log first level auth.info quick from any to 224.0.0.0/3

block in all
block out all

pass in proto icmp icmp-type 3
pass in proto icmp icmp-type 8 keep state
pass out proto icmp icmp-type 3
pass out proto icmp icmp-type 8 keep state

pass in proto udp from any to any port = 53 keep state
pass in proto tcp from any to any port = 22 flags S keep state keep frags
pass in proto tcp from any to any port = 25 flags S keep state keep frags
pass in proto tcp from any to any port = 53 flags S keep state keep frags

pass out proto udp from any to any port = 53 keep state
pass out proto udp from any to any port = 123 keep state
pass out proto tcp from any to any port = 25 flags S keep state keep frags
pass out proto tcp from any to any port = 53 flags S keep state keep frags


Thanks,

Petar

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Petar Bogdanovic]

Post by Petar Bogdanovic
Hi,
I recently noticed that ipfilter with `block return-icmp' is returning
ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4
An ICMP error message MUST NOT be sent as the result of
* an ICMP error message, or
* a datagram destined to an IP broadcast or IP multicast
address, or
* a datagram sent as a link-layer broadcast, or
* a non-initial fragment, or
* a datagram whose source address does not define a single
host -- e.g., a zero address, a loopback address, a
broadcast address, a multicast address, or a Class E
address.
Is this desired behaviour?

Oops, while removing the comments I removed the two most important
lines. Here is my complete ipf.conf:

pass in quick on lo0 all
pass out quick on lo0 all

block in quick from 192.168.0.0/16 to any
block in quick from 172.16.0.0/12 to any
block in quick from 10.0.0.0/8 to any
block in quick from 127.0.0.0/8 to any
block in quick from 0.0.0.0/8 to any
block in quick from 169.254.0.0/16 to any
block in quick from 192.0.2.0/24 to any
block in quick from 204.152.64.0/23 to any
block in quick from 224.0.0.0/3 to any

block out log first level auth.info quick from any to 192.168.0.0/16
block out log first level auth.info quick from any to 172.16.0.0/12
block out log first level auth.info quick from any to 10.0.0.0/8
block out log first level auth.info quick from any to 127.0.0.0/8
block out log first level auth.info quick from any to 0.0.0.0/8
block out log first level auth.info quick from any to 169.254.0.0/16
block out log first level auth.info quick from any to 192.0.2.0/24
block out log first level auth.info quick from any to 204.152.64.0/23
block out log first level auth.info quick from any to 224.0.0.0/3

block in all
block out all

+block return-rst in proto tcp
+block return-icmp in proto udp

pass in proto icmp icmp-type 3
pass out proto icmp icmp-type 3

pass in proto icmp icmp-type 8 keep state
pass out proto icmp icmp-type 8 keep state

pass in proto udp from any to any port = 53 keep state
pass in proto tcp from any to any port = 22 flags S keep state keep frags
pass in proto tcp from any to any port = 25 flags S keep state keep frags
pass in proto tcp from any to any port = 53 flags S keep state keep frags

pass out proto udp from any to any port = 53 keep state
pass out proto udp from any to any port = 123 keep state
pass out proto tcp from any to any port = 25 flags S keep state keep frags
pass out proto tcp from any to any port = 53 flags S keep state keep frags


Petar

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by Petar Bogdanovic

Post by Petar Bogdanovic
I recently noticed that ipfilter with `block return-icmp' is
returning ICMP Type 3 Code 0 (Network unreachable) to the sender of
130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4
An ICMP error message MUST NOT be sent as the result of

[...]

Post by Petar Bogdanovic

Post by Petar Bogdanovic
* a datagram destined to an IP broadcast or IP multicast
address, [...]

+block return-icmp in proto udp

I would say that the resulting behaviour is, strictly, wrong, but that
it's not ipf's fault: it's doing exactly what you told it to do.

I do not see any reason why ipf - or most other pieces of software, for
that matter - have to make it impossible, or even difficult, to violate
standards. Just as I don't expect to be prevented from deleting the
postmaster alias in my mailer, or running 127.0.5.0/24 as an "ordinary"
Ethernet if I try, I don't expect ipf to impose all the Host
Requirements on me.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Wed, 4 Jun 2008 15:03:06 +0200

Post by Petar Bogdanovic
Hi,
I recently noticed that ipfilter with `block return-icmp' is returning
ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4
An ICMP error message MUST NOT be sent as the result of
* an ICMP error message, or
* a datagram destined to an IP broadcast or IP multicast
address, or
* a datagram sent as a link-layer broadcast, or
* a non-initial fragment, or
* a datagram whose source address does not define a single
host -- e.g., a zero address, a loopback address, a
broadcast address, a multicast address, or a Class E
address.
Is this desired behaviour?

I don't see the conflict. The intent of that section of 1122 is to
rule out troublesome ICMPs. The first condition prevents loops; the
second two prevent ICMP implosions, the fourth assumes that the initial
fragment will cause the proper message, and the last is for an ICMP
that can't be delivered to a single host. Your example concerns none
of those cases. Furthermore, the very next page of 1122 defines an
ICMP type code for "administratively prohibited" communication, which
is exactly what I hope ipf is returning here.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Petar Bogdanovic]

} On Wed, 4 Jun 2008 15:03:06 +0200
}
} > I recently noticed that ipfilter with `block return-icmp' is returning
} > ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
} >
} > 130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4
} >
} >
} >
} > An ICMP error message MUST NOT be sent as the result of
} >
} > * an ICMP error message, or
} >
} > * a datagram destined to an IP broadcast or IP multicast
} > address, or
} >
} > * a datagram sent as a link-layer broadcast, or
} >
} > * a non-initial fragment, or
} >
} > * a datagram whose source address does not define a single
} > host -- e.g., a zero address, a loopback address, a
} > broadcast address, a multicast address, or a Class E
} > address.
} >
} >
} > Is this desired behaviour?
}
} I don't see the conflict. The intent of that section of 1122 is to
} rule out troublesome ICMPs. The first condition prevents loops; the
} second two prevent ICMP implosions, the fourth assumes that the initial
Using the English language (which usually works with RFCs) along
with the RFC definition of "MUST NOT", it sure looks like either the
second or third condition applies depending on the link layer address.
} fragment will cause the proper message, and the last is for an ICMP
} that can't be delivered to a single host. Your example concerns none
} of those cases. Furthermore, the very next page of 1122 defines an
} ICMP type code for "administratively prohibited" communication, which
} is exactly what I hope ipf is returning here.
The second line of the stuff you quoted says, "ICMP Type 3 Code 0
(Network unreachable)". "administratively prohibited" would be Code 9,
10, or 13.
The question I have is, is 130.3.3.4 a router of some sort?

No, it's not a router:

# sysctl -a | grep forwarding
net.inet.ip.forwarding = 0
net.inet6.ip6.forwarding = 0

# ifconfig -a | grep '^[a-z]'
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192


Petar

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jim Wise]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Petar Bogdanovic
Hi,
I recently noticed that ipfilter with `block return-icmp' is returning
ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4

Note that IPF makes the return ICMP code configurable. Try:

block return-icmp-as-dest(port-unr)

As noted down-thread, the default return value is perfectly appropriate
for a router, but less so for an end host.

By the way, I think it's a bad idea to configure IPF to return
'administratively prohibited' for blocked ports -- doing so allows a
remote host to easily differentiate between blocked ports and open ports
on which no daemon is currently running.

- --
Jim Wise
***@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (NetBSD)

iD8DBQFIR+sRq/KRbT0KwbwRAv/BAJ9cXZ69BlzNrds0kd2qvPDz+64xhQCfWwxs
oqqjwkpRyW4LMtV3z1MgqJ4=
=+2js
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Petar Bogdanovic]

Post by Jim Wise
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Petar Bogdanovic
Hi,
I recently noticed that ipfilter with `block return-icmp' is returning
ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4

block return-icmp-as-dest(port-unr)
As noted down-thread, the default return value is perfectly appropriate
for a router, but less so for an end host.

I don't think that changing the return code would make ipfilter stop
responding to broadcasts. Or did you mean something else?


Petar

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jim Wise]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Petar Bogdanovic

Post by Jim Wise
block return-icmp-as-dest(port-unr)
As noted down-thread, the default return value is perfectly appropriate
for a router, but less so for an end host.

I don't think that changing the return code would make ipfilter stop
responding to broadcasts. Or did you mean something else?

No, changing the return code would address the concern others have raised
that `network unreachable' is not the right response for a host to return.

On the broadcast question, as Mouse notes, IPF is doing what you told it to
do -- since you've configured IPF to respond with an ICMP error for any
packet which reaches it (there's no dst address clause in your rule), it is
doing so.

More generally, I'm not sure the value you see in having IPF on a _host_
return an ICMP error, as doing so just advertises the host's presence (on
the other hand, _not_ sending an ICMP error from a router would indicate
that the destination address/port was `different'). What are you trying to
accomplish?

- --
Jim Wise
***@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (NetBSD)

iD4DBQFIR/FOq/KRbT0KwbwRApt7AJ4weyw+qVO6qbZTCvvdukYETQ1UBQCYufsU
QdhOfm4PeskLC7A0xfaecQ==
=yaZz
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jim Wise]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Petar Bogdanovic
+block return-rst in proto tcp
+block return-icmp in proto udp

Note that a quick fix would be to treat the broadcast address `specially'
for these rules. So replace the above with:

my_addr="10.2.3.4";
broadcast_addr="10.2.3.255";

block from any to $broadcast_addr
block return-rst in proto tcp
block return-icmp(port-unr) in proto udp from any to $my_addr
block return-icmp in proto udp

This should give the most `realistic' error responses for your non-open
ports, unless I'm missing something (entirely possible).

- --
Jim Wise
***@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (NetBSD)

iD8DBQFISAF6q/KRbT0KwbwRAre0AJ9axo7GmbXchVuUXnlKWq03cVVr9ACfYuTJ
TyFa7AaV0NYc62b4s9f50Hs=
=qAFL
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Petar Bogdanovic]

Post by Jim Wise
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Petar Bogdanovic

Post by Jim Wise
block return-icmp-as-dest(port-unr)
As noted down-thread, the default return value is perfectly appropriate
for a router, but less so for an end host.

I don't think that changing the return code would make ipfilter stop
responding to broadcasts. Or did you mean something else?

No, changing the return code would address the concern others have raised
that `network unreachable' is not the right response for a host to return.
On the broadcast question, as Mouse notes, IPF is doing what you told it to
do -- since you've configured IPF to respond with an ICMP error for any
packet which reaches it (there's no dst address clause in your rule), it is
doing so.
More generally, I'm not sure the value you see in having IPF on a _host_
return an ICMP error, as doing so just advertises the host's presence (on
the other hand, _not_ sending an ICMP error from a router would indicate
that the destination address/port was `different'). What are you trying to
accomplish?

Returning rst/port-unr spares me (and others) timeouts when trying to
connect blocked ports. I often forget about the packet filter; hence an
immediate abort helps me remembering that there was something between..


Petar

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Petar Bogdanovic]

Post by Jim Wise
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Petar Bogdanovic
+block return-rst in proto tcp
+block return-icmp in proto udp

Note that a quick fix would be to treat the broadcast address `specially'
my_addr="10.2.3.4";
broadcast_addr="10.2.3.255";
block from any to $broadcast_addr
block return-rst in proto tcp
block return-icmp(port-unr) in proto udp from any to $my_addr
block return-icmp in proto udp
This should give the most `realistic' error responses for your non-open
ports, unless I'm missing something (entirely possible).

I tried to avoid using host-dependent addresses in my filter rules,
since this copy of ipf.conf gets distributed among multiple hosts.

But maybe I should leave this path. Thanks for the hint.


Petar

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Sep 20, 9:40pm, Jim Wise wrote:
} On Wed, 4 Jun 2008, Petar Bogdanovic wrote:
}
} >I recently noticed that ipfilter with `block return-icmp' is returning
} >ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
} >broadcast:
} >
} > 130.3.3.3 ---------[***@130.3.3.255]--------> 130.3.3.4
} > 130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4
} >
} >
} >This seems wrong, considering RFC1122, page 39:
}
} Note that IPF makes the return ICMP code configurable. Try:
}
} block return-icmp-as-dest(port-unr)
}
} As noted down-thread, the default return value is perfectly appropriate
} for a router, but less so for an end host.
}
} By the way, I think it's a bad idea to configure IPF to return
} 'administratively prohibited' for blocked ports -- doing so allows a
} remote host to easily differentiate between blocked ports and open ports
} on which no daemon is currently running.

At the very least, I would return some kind of error for packets
headed to port 113 (ident) as a courtesy so that people/apps don't have
to wait for a timeout.

P.S. To anybody inclined to respond, I'm not interested in arguments
about the usefulness of the ident protocol.

}-- End of excerpt from Jim Wise

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by John Nemeth
At the very least, I would return some kind of error for packets
headed to port 113 (ident) as a courtesy so that people/apps don't
have to wait for a timeout.

Yeah, but that's TCP, and you want an RST rather than an ICMP
unreachable (return-rst, I think, is the keyword).

Post by John Nemeth
P.S. To anybody inclined to respond, I'm not interested in arguments
about the usefulness of the ident protocol.

Yeah, far too many people think it's supposed to be something it's not,
and then point out - at exhausting length - how thoroughly it fails to
be that thing it's not trying to be. :-/

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Sep 20, 10:07pm, Jim Wise wrote:
} On Thu, 5 Jun 2008, Petar Bogdanovic wrote:
}
} >> Note that IPF makes the return ICMP code configurable. Try:
} >>
} >> block return-icmp-as-dest(port-unr)
} >>
} >> As noted down-thread, the default return value is perfectly appropriate
} >> for a router, but less so for an end host.
} >
} >I don't think that changing the return code would make ipfilter stop
} >responding to broadcasts. Or did you mean something else?
}
} No, changing the return code would address the concern others have raised
} that `network unreachable' is not the right response for a host to return.
}
} On the broadcast question, as Mouse notes, IPF is doing what you told it to
} do -- since you've configured IPF to respond with an ICMP error for any
} packet which reaches it (there's no dst address clause in your rule), it is
} doing so.

This may be so based on a strict reading of the syntax, but it
would be nice if IPF behaved in a sensible way by default and you had
to explicitly misconfigure it in order to get improper behaviour.

}-- End of excerpt from Jim Wise

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jim Wise]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by John Nemeth
} On the broadcast question, as Mouse notes, IPF is doing what you told it to
} do -- since you've configured IPF to respond with an ICMP error for any
} packet which reaches it (there's no dst address clause in your rule), it is
} doing so.
This may be so based on a strict reading of the syntax, but it
would be nice if IPF behaved in a sensible way by default and you had
to explicitly misconfigure it in order to get improper behaviour.

Well, the default behavior is arguably right for a router (the more
common IPF use case. In any case, the error should be a rare one --
sssuming proper config of border routers, any broadcast packet you see
reaching a host will have originated on the local subnet (or close), so
such a response should be rare and local.

- --
Jim Wise
***@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (NetBSD)

iD8DBQFISFVnq/KRbT0KwbwRAtRfAJ9I0/unNj8huw5bS7ysgjMYA0r2RQCfVIVj
3nWdaQ+kd0xndYhdzOQ3GOM=
=a+1H
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by Jim Wise

Post by John Nemeth
} On the broadcast question, as Mouse notes, IPF is doing what you told it to
} do -- since you've configured IPF to respond with an ICMP error for any
} packet which reaches it (there's no dst address clause in your rule), it is
} doing so.
This may be so based on a strict reading of the syntax, but it
would be nice if IPF behaved in a sensible way by default and you had
to explicitly misconfigure it in order to get improper behaviour.

Well, the default behavior is arguably right for a router (the more
common IPF use case. In any case, the error should be a rare one --
sssuming proper config of border routers, any broadcast packet you see
reaching a host will have originated on the local subnet (or close), so
such a response should be rare and local.

I'm not clear on how this behaviour could be argued to be any more
correct
for a router than a host. Here's what RFC 1812 says:

4.3.2.7 When Not to Send ICMP Errors

An ICMP error message MUST NOT be sent as the result of receiving:

o An ICMP error message, or

o A packet which fails the IP header validation tests described in
Section [5.2.2] (except where that section specifically permits
the sending of an ICMP error message), or

o A packet destined to an IP broadcast or IP multicast address, or

o A packet sent as a Link Layer broadcast or multicast, or

o A packet whose source address has a network prefix of zero or is
an
invalid source address (as defined in Section [5.3.7]), or

o Any fragment of a datagram other then the first fragment (i.e., a
packet for which the fragment offset in the IP header is
nonzero).

Furthermore, an ICMP error message MUST NOT be sent in any case
where
this memo states that a packet is to be silently discarded.

NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT
ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.

There are good reasons why these rules exist. I buy the notion
that your computer should do what you tell it to do no matter what
the standards say, but I think there should be a way to configure
behaviour which conforms to the standard which is at least as simple
as doing the broken configuration is, and I don't think it is a
good idea to make doing the right thing depend on the assumption
that other boxes are behaving the way you expect.

Note that for broadcasts in particular the "link level" constraint
is important. It is quite possible to receive packets as link-level
broadcasts which have IP destination addresses which don't look anything
like a broadcast address.

Dennis Ferguson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jim Wise]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Jim Wise
Well, the default behavior is arguably right for a router (the more
common IPF use case. In any case, the error should be a rare one --
sssuming proper config of border routers, any broadcast packet you see
reaching a host will have originated on the local subnet (or close), so
such a response should be rare and local.

I'm not clear on how this behaviour could be argued to be any more correct

It's clear that a router should be rejecting a broadcast packet which
would transit that router in almost all cases.

If the network behind the router is otherwise firewalled, the router
should return the same error as it would for any other address on that
network -- otherwise, the router's lack of a response would confirm the
existence of the otherwise-firewalled network (a non-configured network
having no broadcast address).

- --
Jim Wise
***@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (NetBSD)

iD8DBQFISHwXq/KRbT0KwbwRAnLLAJ9BcmaR0jd/P8SLANW1OZYjnpHo+wCePc2P
+/Ohm+xHyFRqNfhNHIxLkgE=
=3FQY
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by Jim Wise

Post by Jim Wise
Well, the default behavior is arguably right for a router (the more
common IPF use case. In any case, the error should be a rare one --
sssuming proper config of border routers, any broadcast packet you see
reaching a host will have originated on the local subnet (or
close), so
such a response should be rare and local.

I'm not clear on how this behaviour could be argued to be any more correct

It's clear that a router should be rejecting a broadcast packet which
would transit that router in almost all cases.

Broadcast-addressed packets should never transit a router which is
working
properly by default, firewall or not.

That's not the bit which bothers me, though. Routers and hosts should
generally never send an error packet in response to a packet which
arrives
as a link level broadcast or multicast no matter what the IP destination
address in the packet is (there are lots of ways for packets to arrive
as link-level broadcasts with addresses which can't be identified as
"broadcast" addresses), since doing so can break things. While
configuring
the router to do that anyway is fine with me, it should be at least as
easy to configure the router to do the right thing.

Post by Jim Wise
If the network behind the router is otherwise firewalled, the router
should return the same error as it would for any other address on that
network -- otherwise, the router's lack of a response would confirm the
existence of the otherwise-firewalled network (a non-configured network
having no broadcast address).

That's a different issue, if I understand it. Subnet-specific broadcast
addresses are only broadcast addresses on the subnet with that address.
If they arrive on another interface you can do anything you would
normally
do with any packet addressed to the same subnet, firewall or not, except
that by default the router shouldn't forward the packet onto the subnet
where it would be broadcast.

That is a different issue than the handling of packets which arrive as
link-level broadcasts, however, no matter what address is in the packet.
These should normally be silently eaten.

Dennis Ferguson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Thu, 5 Jun 2008 18:30:56 -0700

Post by Dennis Ferguson
Broadcast-addressed packets should never transit a router which is
working
properly by default, firewall or not.

You're quite correct. Note well, though, that 1122 is *host*
requirements, and very deliberately does not discuss *router*
requirements.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by Steven M. Bellovin
On Thu, 5 Jun 2008 18:30:56 -0700

Post by Dennis Ferguson
Broadcast-addressed packets should never transit a router which is
working
properly by default, firewall or not.

You're quite correct. Note well, though, that 1122 is *host*
requirements, and very deliberately does not discuss *router*
requirements.

That's true, but the constraints on sending ICMP errors in section
4.3.2.7 of RFC 1812 are pretty much identical to those of section
3.2.2 in 1122. On the particular, limited topic of when to not
send ICMP errors the distinction between hosts and routers doesn't
matter much.

Dennis Ferguson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Subnet-specific broadcast addresses are only broadcast addresses on
the subnet with that address. If they arrive on another interface
you can do anything you would normally do with any packet addressed
to the same subnet, firewall or not, except that by default the
router shouldn't forward the packet onto the subnet where it would be
broadcast.

You mean that the "don't send ICMPs in response to packets sent to
broadcast addresses" actually means "...to packets sent to what on the
incoming interface is a broadcast address"?

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by Dennis Ferguson
o A packet destined to an IP broadcast or IP multicast address,

Unfortunately, this is unimplementable as written.

For example, a packet destined to 216.46.5.15 is "destined to an IP
broadcast ... address". But how is anyone except me and my immediate
upstream supposed to know that? Everyone else will perforce treat such
packets just like their non-broadcast relations addressed to, say,
216.46.5.14 - including ICMP generation.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by der Mouse

Subnet-specific broadcast addresses are only broadcast addresses on
the subnet with that address. If they arrive on another interface
you can do anything you would normally do with any packet addressed
to the same subnet, firewall or not, except that by default the
router shouldn't forward the packet onto the subnet where it would be
broadcast.

You mean that the "don't send ICMPs in response to packets sent to
broadcast addresses" actually means "...to packets sent to what on the
incoming interface is a broadcast address"?

Yes, that's a good way to put it.

That treatment applies to more than just sending ICMP errors, actually.
If you have an application which receives packets which might be
sent with a broadcast, you would only recognize packets to a subnet
broadcast address as packets addressed to "you" if they arrived on
an interface on that subnet.

Dennis Ferguson

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Sep 20, 11:16pm, Jim Wise wrote:
} On Wed, 4 Jun 2008, Petar Bogdanovic wrote:
}
} > +block return-rst in proto tcp
} > +block return-icmp in proto udp
}
} Note that a quick fix would be to treat the broadcast address `specially'
} for these rules. So replace the above with:
}
} my_addr="10.2.3.4";
} broadcast_addr="10.2.3.255";
}
} block from any to $broadcast_addr
} block return-rst in proto tcp
} block return-icmp(port-unr) in proto udp from any to $my_addr
} block return-icmp in proto udp
}
} This should give the most `realistic' error responses for your non-open
} ports, unless I'm missing something (entirely possible).

IPF rules are last match, so wouldn't this cause the same
problem? Should the "block from any to $broadcast_addr" be at the
bottom?

}-- End of excerpt from Jim Wise

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jim Wise]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by John Nemeth
} Note that a quick fix would be to treat the broadcast address `specially'
}
} my_addr="10.2.3.4";
} broadcast_addr="10.2.3.255";
}
} block from any to $broadcast_addr
} block return-rst in proto tcp
} block return-icmp(port-unr) in proto udp from any to $my_addr
} block return-icmp in proto udp
}
} This should give the most `realistic' error responses for your non-open
} ports, unless I'm missing something (entirely possible).
IPF rules are last match, so wouldn't this cause the same
problem? Should the "block from any to $broadcast_addr" be at the
bottom?

Yes, or rather, the rules should use 'block quick'.

- --
Jim Wise
***@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (NetBSD)

iD8DBQFISFSuq/KRbT0KwbwRAln6AJ9yXO68qMyWBA0CoyVL5984Bhh9LgCdGJ6V
ZxYc778ikGsmJVeDjvu+Arc=
=i1Hb
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Jim Wise

Post by Petar Bogdanovic
+block return-rst in proto tcp
+block return-icmp in proto udp

Note that a quick fix would be to treat the broadcast address `specially'
my_addr="10.2.3.4";
broadcast_addr="10.2.3.255";
block from any to $broadcast_addr
block return-rst in proto tcp
block return-icmp(port-unr) in proto udp from any to $my_addr
block return-icmp in proto udp
This should give the most `realistic' error responses for your non-open
ports, unless I'm missing something (entirely possible).

You don't need to specify the broadcast address:

block in quick all with bcast

And if you needed to do this for both broadcast and multicast:

block in quick all with mbcast

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[j+ (Jukka Salmi)]

Post by Darren Reed
block in quick all with bcast
block in quick all with mbcast

Nice! Is this documented somewhere (outside the yacc grammar)? I can't
find any reference to {m,}bcast in ipf(5).


Regards, Jukka

[Darren Reed]

Post by Darren Reed

Post by Jim Wise

Post by Petar Bogdanovic
+block return-rst in proto tcp
+block return-icmp in proto udp

Note that a quick fix would be to treat the broadcast address
`specially'
my_addr="10.2.3.4";
broadcast_addr="10.2.3.255";
block from any to $broadcast_addr
block return-rst in proto tcp
block return-icmp(port-unr) in proto udp from any to $my_addr
block return-icmp in proto udp
This should give the most `realistic' error responses for your non-open
ports, unless I'm missing something (entirely possible).

block in quick all with bcast
block in quick all with mbcast

And you can also do:

block in quick on fxp0 from any to fxp0/bcast

(interface name in the "address" field must match the "on" name)

Cheers,
Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de