[76823] in North American Network Operators' Group
FW: Smallest Transit MTU
daemon@ATHENA.MIT.EDU (David Schwartz)
Fri Dec 31 03:58:22 2004
From: "David Schwartz" <davids@webmaster.com>
To: "Nanog@Merit. Edu" <nanog@merit.edu>
Date: Fri, 31 Dec 2004 00:57:24 -0800
X-MDaemon-Deliver-To: nanog@merit.edu
Reply-To: davids@webmaster.com
Errors-To: owner-nanog-outgoing@merit.edu
Last post on this, I hope.
> > The argument I am taking issue with is whether or not it's
> > a mistake for a
> > firewall or end system to drop packets with reserved bits set
> > -- bits that
> > by RFC/BCP MUST be zero on transmission.
> Now I know you've not yet read BCP 60. :-)
>
> John
Sure, it's easy to make the right decision once you know
how the bits are going to be used. BCP 60 is based upon
information that was not available at the time the decision was
made. I am defending the decision to configure firewalls (before
ECN was deployed) to drop packets that had this bit set, assuming
you had the requisite cluefulness to maintain such a decision.
The view I am opposing is that this decision was
unreasonable to make at the time it was made. To say, "you should
have anticipated ECN and BCP 60" is not only unreasonable but
gets the simple reply, "well, then you change the configuration".
Firewall configurations almost always have to be changed when new
protocols or features are deployed.
>> > I see. Can you suggest a firewall that supports "block all
>> >traffic not
>> > unencrypted and in American English"?
>>
>> You misunderstand what I mean by "whose meaning is not known".
>> Deliberately, I suspect.
>He *does* have a point - the fact that the firewall knows about the new
>feature doesn't mean that the target host behind the firewall is able to
>do something reasonable/correct with the new feature....
Precisely. That's why you can't make the decision without
knowing what you're talking about. For firewalls, one generally
errs on the side of security and accepts that changes may result
in inconvenience until configurations can be maintained.
>And where, exactly, do you draw the line between "firewall that blocks
>unknown bits" and "virus-scanning front-end appliance that blocks unknown
>MIME types" and "Great Firewall" that blocks all traffic that contains
>subversive content.....
Wherever you need to, based upon available technology,
needs, and cluefulness. I am not saying the decision doesn't need
to be made, I'm defending a slightly different balance on the
assumption of only slight cluefullness. A cluelessly maintained
firewall is never a good thing.
I'm kind of surprised this went on as long as it did. All
I'm saying is that, when possible and there's sufficient clue to
maintain it, firewalls should be configured to block everything
unknown, to the extent possible. This includes packets with bits
set in the header whose meaning is unknown and which are mandated
to be cleared by existing RFCs. This imposes the slight burden
that the firewall configuration has to be updated when new
protocols or features are deployed -- but this is (or at least
should be) always the case with firewalls.
Nobody's saying this is acceptable for transit networks.
Just firewalls and end hosts.
DS
