RE: ISMS working group and charter problems

>>> 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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf