[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ipfilter, return-icmp and RFC1122
On 5 Jun 2008, at 14:06 , Jim Wise wrote:
On Thu, 5 Jun 2008, John Nemeth wrote:
} 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
} 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),
such a response should be rare and local.
I'm not clear on how this behaviour could be argued to be any more
for a router than a host. Here's what RFC 1812 says:
18.104.22.168 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
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
Furthermore, an ICMP error message MUST NOT be sent in any case
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.
Main Index |
Thread Index |