FW: Smallest Transit MTU

["David Schwartz" <davids () webmaster com>]

        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