Hi Colin, See inline... Tom P. > -----Original Message----- > From: Colin Perkins [mailto:csp@xxxxxxxxxxxxx] > Sent: Thursday, February 21, 2008 9:00 AM > To: Phelan, Tom > Cc: 'dccp' working group > Subject: Re: draft-phelan-dccp-natencap-00.txt > > Tom, > > On 18 Feb 2008, at 18:35, Phelan, Tom wrote: > > On the second issue in your e-mail, whether the NAT traversal mode of > > DCCP should be transparent to applications or not: There were a few > > issues that drove me towards application visibility. > > > > I felt that applications would want to know directly that NAT > > traversal > > mode was available or not and that it would be used or not. This is > > similar to why I perceive TLS is more popular with apps than IPsec. > > Apps could migrate to IPsec without making changes, yet they seem to > > prefer TLS. There are perhaps many reasons for this, but I think > > one of > > them is because TLS gives them more visible and direct control over > > what's going on. > > > > Perhaps this thinking doesn't apply here -- if NAT traversal mode were > > widely available in DCCP implementations and the negotiation to > > choose a > > mode was efficient then apps wouldn't care. But my initial take was > > that the added complexity and the likely time involved in settling > > on an > > encapsulation (if your first guess was wrong) were enough > > disadvantages > > to argue for the no-negotiation approach. > > For the TLS case, the application wants to do something different if > the security is enabled. I'm not sure that's the case for native vs. > encapsulated DCCP, so the parallel doesn't follow. > [Tom P.] Well, in this case the app also wants to do something different -- pass through NATs. And in TLS/IPsec, the apps get arguably somewhat better security with IPsec, but still opted for TLS. > > Another issue with automatic negotiation is that apps that used > > another > > signaling protocol to rendezvous (such as SIP/SDP) would need to carry > > info for all encaps, even when they knew they needed only one (they'd > > need to carry the UDP port of the DCCP-NAT service, plus the DCCP > > port). > > How big an issue this is, since we're at the very early stages of > > defining any of these protocols, is debatable. > > I was envisaging the DCCP-over-UDP tunnel being invisible to the SDP > layer, but maybe that won't work. > > -- > Colin Perkins > http://csperkins.org/ >
