RE: [BEHAVE] Re: CPE equipments and stateful filters

["Dan Wing" <dwing@cisco.com>]

> No.  Passive-mode FTP is broken for exterior clients connecting to  
> interior servers by stateful packet filters.  Merely allowing 
> the FTP  
> control port through the filter to the interior server is  
> insufficient. 

You're right.  Thanks for pointing out my mistake in assuming
the FTP server wouldn't, itself, be behind a similar firewall.

> Requiring FTP clients and servers to use TCP  
> simultaneous open for data connections could address this problem,  
> but I've been using FTP as an example to illustrate the wider 
> problem with applications in general.
> 
> We still have an open problem regarding IKE and IPsec ESP/AH, and I  
> don't see a comparable way to resolve it without an application  
> transparency helper or by allowing inbound ESP/AH by default.   It  
> remains to be seen whether consensus will emerge around the latter  
> solution, so I contend the former remains an open problem.

I don't see why you'd allow unsolicited ESP or AH, but deny other
protocols (ICMP, UDP, TCP, SCTP, DCCP).  It seems we need to solve
this problem for all protocols.  Certainly, if one is considering
a battery-powered host, where receiving any packet will wake up
the radio and host processor, unsolicited IPsec packets shouldn't 
be allowed any more so than unsolicited UDP or TCP.

> There are similar issues with RTSP

RTSP control traffic over TCP?

> and RTCP/RTP flows. 

At this point, ICE (draft-ietf-mmusic-ice) is believed to provide
a viable, incrementally deployable mechanism for IPv4 and IPv6, 
including if you're behind a NAT or firewall if that NAT or firewall
allows packets from inside->outside to create permissions for 
outside->inside; most NATs available to consumers work like that
and all firewalls can be configured like that.

> And other  
> existing application protocols.  Not to mention applications not  
> imagined by their developers yet.  And and and.  So long as the IPv6  
> architecture is defined such that communications between endpoints  
> are always expected to originate with nodes behind firewalls and  
> mediated by services in data centers, we will be saddled with the  
> need for either 1) application transparency helpers inside network  
> firewalls, and/or 2) an improvement to the core IPv6 specifications  
> along the lines of my Application Listener Discovery (ALD) proposal.

I see ALD being helpful for both the case of talking to a well-
known server in a datacenter, and also being helpful for peer-to-
peer applications, such as running an FTP client when you're behind
a firewall trying to communicate with an FTP server that is also behind
a firewall.

> > I do hope you pursue a BoF in Vancouver to discuss the need for
> > endpoints to communicate to firewalls in IPv6.
> 
> I'm working on socializing that plan with my management.

Good deal.

-d