Security policies are determined by network administrators, corporate security departments, or organizational entities. Any protocol that chooses to overload an existing method with new functionality is, in effect, causing a deployed PFB security policy to differ from the intent of the administrator. The key point here is that by overloading POST to support, for example, IPP, the PFB is now permitting a new printing protocol by default. While it may be tempting to pursue this way of doing things because the new protocol will be supported in a ubiquitous manner with no administrative effort required whatsoever, one should carefully consider the consequences. While the designers of a new protocol may feel that their new protocol introduces no new risks, they do not have the right to decide what a PFB will support.
Security policies vary from very relaxed ones to extremely restrictive ones.
However, we believe that protocols should be designed to represent and support the most conservative default action. 3 Semantic exposure for specific ACLs On most firewalls today, the administrator is given many methods for constructing his security policy. Often, he or she is able to choose between characteristics like source port, dest port, header prologue, HTTP method, mime-type, etc. Some PFBs support these methods as well as others, some support only a subset. We contend that there is an onus on a protocol designer to expose the security aspects or operational semantics as they may pertain to security in the easiest manner to facilitate easily constructed ACLs.