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

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

> On Jul 30, 2007, at 15:47, Dan Wing wrote:
> > [I wrote:]
> >>
> >> There are similar issues with RTSP
> >
> > RTSP control traffic over TCP?
> 
> Yes.  As seen in QuickTime and RealPlayer applications.
> 
> >> 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.
> 
> Existing code (which does support IPv6) has no support for ICE.
>
> Even in the event ICE isn't deployed, how do you recommend I resist  
> the inevitable pressure to implement an application transparency  
> helper for these A/V streaming applications? 

With ICE, such application helpers are not necessary.  This was one
of the major design decisions in ICE.  This is the same design 
descision that allows Skype to "work anywhere".  

> I'm still having to  
> maintain ALG's in IPv4/NAT for various VPN protocols even though we  
> have long had standards track protocols for IPsec 
> encapsulated in UDP and negotiating NAT traversal of IKE.

The only IPsec client implementation I'm aware of is Cisco's, and
I know our implementation does not provide automatic detection or
fallback from IPsec-over-IP to IPsec-over-UDP; rather, the user has
to select this themselves or be artificially limited to always use
UDP.  IPsec-over-UDP is, of course, less bandwidth efficient than
IPsec-over-IP.

It's important to have such automatic fallback mechanisms.  ICE
provides these automatic fallbacks by using connectivity checks.

We know how to multiplex those connectivity checks with RTP/RTCP, 
DTLS, TLS, HIP, and SIP.  I expect ICE connectivity checks could
be multiplexed with many other protocols.  I am not suggesting ICE
is the ideal solution for a host to tell its v6 firewall that it
desires incoming traffic -- I am just explaining how ICE works 
as a datapoint.  You may find it valuable to read the first 
two sections of ICE (and ignore the detail).  Also, Jonathan 
Rosenberg gave an ICE tutorial in Chicago, posted at 
http://www.jdrosen.net/papers/ice-ietf-tutorial2.ppt.  Like you,
I wasn't present at the Thursday technical plenary but I listened
to the audio,
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch5-thurs-
afnoon-plenary.mp3

> I'm expecting to have to implement a helper for IKE and IPsec ESP/AH  
> in IPv6.  Without it, I expect route optimization in Mobile IPv6 to  
> be broken, since mobile nodes are supposed to bind with their home  
> agents using an IPsec ESP security association.  In fact, the more I  
> read about route optimization in MIPv6, the more convinced I am that  
> it represents the most glaring illustration yet of our failure to  
> consider properly the implications of recommending the widespread  
> deployment of stateful middlebox packet filtering in IPv6 networks.

http://tools.ietf.org/html/draft-tschofenig-mip6-ice-01 describes 
how ICE might be useful for Mobile IPv6.

-d