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