>>> Actually, a "Firewall Considerations" section would make sense. >> Agreed. >>What would be in such a section? There are only three possibilities: >> >>1. There is no firewall: no need for text. >>2. There is a firewall, and it doesn't try to block the protocol: no >>need for text. >>3. There is a firewall, and it tries to block the protocol. >> >>So what text would be helpful in case #3? Either the firewall >>successfully blocks the protocol and the firewall works and the >>protocol doesn't, or the firewall doesn't manage to block the protocol >>and the protocol works but the firewall doesn't. So whatever happens, >>someone is going to be unhappy. >> >Not at all. Often, a firewall needs to know a fair amount about the protocol to do its job. FTP is the simplest >case -- it has to look for the PORT (and, in some configuration, the PASV) command. H.323 and SIP are more >complex. > Exactly, ignoring the particulars of a protocol and choosing to just block/not block it doesn't really make the firewall useful to that protocol. That's certainly one of the valid choices for a firewall to take, however. >But for complex protocols, we need to go a step further. SIP has, built-in, provision for gateways. There are a >number of reasons for this, but firewall friendliness is certainly one of them. The proper question is this: >>would adding something to the protocol enable it to operate properly in the presence of a firewall *without* >>subverting site security policy. The lack of that latter consideration has led to people using http as the >>universal firewall traversal protocol, with the obvious bad side-effects. Indeed this section could be a way of documenting the proper behavior of a firewall in the context of a certain protocol. For example a firewall could say with regard to protocol X I either: A) treat it as unknown/don't recognize the protocol <- this is fine if you don't use the protocol B) meet the full criteria specified in the "Firewall Considerations" section <-this may be a factor if the particular protocol receives heavy use in your organization C) Do something inbetween, which while possibly helpful should not be considered compliant for the sake of differentiating devices. Much like you can configure port forwarding and a DMZ among a multitude of other things commonly on firwall/nats allowing for the possibility of consistent behavior/options relating to a new protocol among firewall vendors MUST be better than leaving it to itself like has happened with the NAT situation. -Tom _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf