Re: firewall and NAT I-D available

[Jiri Kuthan <[e-mail]>]

Jonathan,

draft-rosenberg-sip-firewalls is a very useful I-D that covered 
a big gap successfully.

Some points follow that I have discussed with my colleagues recently.
(The conclusion is that a kind of firewall control protocol is 
needed. Initial requirements are described in a separate I-D.)

1) You suggest using SOCKS (Section 5) as a possible alternative for 
   "Firewall Control Protocol" (FCP). I am not sure SOCKS will help
   even without NAT.

   The discussed scheme looks like this:A packet filter implements 
   'default-deny'  policy which explicitly permits traffic from and 
   to SIP Proxy (ALG in generic terms). The SIP Proxy is in charge 
   of opening pinholes in the packet filters during a SIP session.

                                SIP     
          SIP   +---------+_____________     |
        ________|SIP Proxy|             \    |
       /        +---------+..           +----+---------------+
      |                     :           |                    |
      |                     :    FCP    +-----+------------+ |
      |                     :...........| FCP | Filtering  | |
      |    FTP  +---------+.............| unit| Rules Table| |
      |    _____|FTP Proxy|_____________+-----+------------+ |
      |   /     +---------+             |  Packet Filter     |
      |   |                        -----|                    |
   +-----------+                  /     +----+---------------+
  +-----------+|   data streams  /           |
 +-----------+||----------------/            |
 |end-devices||  (RTP, ftp-data, etc.)       |
 +-----------+                               |
                                             |
        Inside                               |       Outside


   With SOCKS, there is a UDP relayer which is most likely colocated
   with the packet filter to avoid introducing an additional hop
   along the data path. Then, the SIP Proxy needs to instruct the
   UDP relayer to receive incoming media streams. Unfortunately, 
   SOCKS V5 does not allow to bind to publicly available *UDP*
   ports and receive at it. (The same problem applies if the end
   devices communicate with SOCKS server on their own.) Some 
   documentation at www.socks5.com  claims this is/will be fixed 
   in V6. You could fix it by issuing a "UDP ASSOCIATE" command 
   that would permit streams going to receivers address. This would 
   possibly require the sender to be SOCKS-aware and encapsulate UDP 
   packets in SOCKS wrappers; at least this is how I understand RFC
   1928 saying "Each UDP datagram carries a UDP request header with 
   it."

   I also guess, that even if SDP included sender's port number there
   would be no way to communicate them to SOCKS server.

2) The scheme above implies many filtering rules, at least compared
   to numbers common today. This may have performance implications.
   I would suggest including a "performance issues" section which
   states this problem. Briefly: too may rules->rule lookup
   computationaly expensive->increased packet latency. Algorithm
   allowing for fast lookup in big frequently changing flow tables
   are needed. These issues have been researched intensively, for 
   example in:

   [1] A. Feldmann, S. Muthukrishnann: Tradeoffs for Packet
Classification. 
	In Proc. IEEE INFOCOM 2000, 2000.
   [2] V. Srinivasan, S. Suri, G. Varghese: PAcket Classification Using 
	Tuple Space Search. In Proc. ACM SIGCOMM '99, 1999.
   [3] P. Gupta, N. McKeown: Packet Classification on Multiple Fields. 
	In Proc. ACM SIGCOMM '99, 1999.

3) I guess it would be useful to say explicitly that a SIP proxy
controlling
   a firewall needs to keep state during the entire session in order to
   be able to close appropriate pinholes on session termination. (This
   probably belongs to the last paragraph in Section 5, if I did not
   overlook it somewhere else.)

4) My understanding of Section 6.6 is you assume hard-state filtering
   rules in packet filters and tearing them down by SIP proxies. 
   I would say that  the expiry timeout should tick where the state 
   resides. The packet filter could maintain timeouts on its own, 
   possibly giving ALGs chance to set up  the expiration time, because 
   ALGs understand best how long period is appropriate to specific 
   applications. SIP proxy may then simply translate
   SIP keep-alive-messages into filtering-rule-keep-alive-messages. It
   works in case of UA as well es proxy (which is stateful, see point 3)
   failure.

5) Summary: there is no existing applicable protocol for firewall
   control. This protocol is needed to allow ALGs to reside out of
packet
   filters. Which is, IMHO, desirable since it allows to reuse existing 
   logic sitting in ALGs (SIP proxies) and relieves *packet* filters
from
   performing application filtering. We need to summarize requirements
for 
   firewall control protocol and see if there is an existing protocol we 
   could reuse (e.g. extended SOCKS, or SNMP with a "packet filter MIB"
or
   whatever).

   I made an attempt to capture the basic requirements and submitted it
   as draft-kuthan-fcp-00.txt. Until it appears in IETF directories it
is
   available at

http://www.fokus.gmd.de/research/cc/glone/employees/jiri.kuthan/private/draft-kuthan-fcp-00.txt

  Unfortunately, I will be off-line and not able to join discussion
  before March 21st.

Jiri

Jonathan Rosenberg wrote:
> 
> Folks,
> 
> Some colleagues and I have written and Internet Draft on getting SIP
> through firewalls and NATs. It discusess the various configurations and
> problems, and describes in detail the processing required to get things
> working. The draft should appear in the archives shortly. Until it does,
> you can pick up a copy at:
> 
> http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-firewalls-00.txt
> 
> Thanks,
> Jonathan R.
> --
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120
> dynamicsoft                                 West Orange, NJ 07052
> [e-mail]                     FAX:   [phone]
> http://www.cs.columbia.edu/~jdrosen         PHONE: [phone]
> http://www.dynamicsoft.com

-- 
Jiri Kuthan		  Phone: +(49) / 30 - 3463 7 271
GMD FOKUS                 Fax  : +(49) / 30 - 3463 8 271
Kaiserin-Augusta-Allee 31 E-Mail : [e-mail]
D-10589 Berlin, Germany   WWW    : http://www.fokus.gmd.de/usr/kuthan