On Apr 11, 2007, at 6:27 AM, james woodyatt wrote:
Doesn't SOCKS/GSSAPI open pinholes in firewalls?
I don't think so. My understanding of SOCKS is that it's for application layer proxies, not network layer stateful packet filtering firewalls. I could be wrong.
It does indeed. I guess I thought that was what you were asking for in addition to what a stateful firewall does automagially.
And the stateful firewalls I am most familiar with actually open pinholes automagically. They observe SYN-etc messages going out and open pinholes for the responses. Where one needs to do more is with protocols where the originatig message is incoming. I would expect (in keeping with the stateful firewalls I am most familiar with) that this is done with an access list that allows SMTP to the incoming mail server, WWW to the web server, and so on. A SIP proxy can similarly open a pinhole for a SIP data call.
The problem arises when a new application protocol is deployed for which an application layer gateway has not been implemented in the stateful packet filter of the IPv6 gateway.
hmm. I wasn't aware that application layer gateways were required. The one I am most familiar with has options for ALGs, but absent them simply allows you to say things like
ip access-list permit smtp any host smtp.example.com
That done, TCP port 25 traffic from anywhere to the system smtp.example.com goes through the firewall. Assuming that's your preferred incoming MTA, that's all the pinhole you need.
I can easily write an ALG for the file transfer protocol that inspects the FTP control stream for the PASV and PORT commands and punches pinholes for the inbound TCP data connection.
ip access-list permit ftp any host ftp.example.com
ip access-list permit ftp-data any host ftp.example.com
In the other direction, the stateful firewall already does what you want. It observes the outgoing SYN and temporarily opens up to accept the corresponding SYN-ACK. That does't handle ACTIVE FTP, but PASSIVE works fine.
In fact, it's on my short list of immediate things to do. This is a straightforward adaptation of the existing FTP ALG in our IPv4/NAT. I can do the same thing for SIP, and BitTorrent, and ISAKMP, and, and, and... but how do I support application protocols that haven't been designed yet?
I'm struggling with what's hard about that if you keep network layer devices looking at the network layer and maybe the port numbers from the transport header. Why do you want your firewall mucking around inside your data?