Re: [tae] New draft: announcing the supported transports via DNS

[Caitlin Bestler <[e-mail]>]

On Sep 18, 2009, at 1:57 PM, Bryan Ford wrote:
>>
>
> Directory-based solutions - or "out-of-band" solutions in general -  
> don't eliminate that risk, because as Dan just pointed out, in-band  
> probes are necessary anyway because a middlebox might (read: usually  
> will, on the IPv4 Internet) block the use of a new transport even if  
> the remote endpoint (truthfully) declares that it is supported.  Out- 
> of-band communication simply cannot reliably provide the information  
> that is really needed on the Internet as it exists: out-of-band  
> information can at best serve as hints at which alternatives to try  
> (or to try first).
>
> Further, although the extra message is probably unavoidable in  
> certain scenarios, in others it could potentially avoided with a bit  
> of cooperation between the alternative transport protocols and the  
> negotiation mechanism.  That was the basic gist of the paper I  
> mentioned earlier on this list, which will appear (probably in  
> slightly revised form) in this year's HotNets:
>
> 	"An Efficient Cross-Layer Negotiation Protocol"
> 	http://bford.info/pub/net/nego.pdf


This is an excellent reference for the discussion. However, I think  
your presentation under-evaluates
the probability that the tail end on a n-step negotiation will have to  
be a conventional 3 or 4-way
handshake with an existing protocol. A totally new "connection  
negotiation protocol" could indeed
be used to convey some of the same information that the first steps of  
existing protocols exchange,
but this would not be known to stateful middle-boxes or intrusion  
detection systems.

>
> Finally, one more point in favor of in-band over out-of-band  
> solution is that you only need _one_ in-band solution, whereas with  
> out-of-band solutions you need to define one for each directory  
> protocol you care about (maybe only DNS, but that's one), PLUS a  
> separate one for each other protocol that exchanges IP addresses for  
> the purpose of setting up transport connections (e.g., SIP,  
> FTP, ???).  Do we really want to have to define and deploy N  
> different negotiation extensions, one for each protocol that  
> produces IP addresses in one way or another?
>
>> I think the following objectives need to be met for any probe-based  
>> solution:
>>
>> 1) Must add no additional messages when the default protocol is  
>> selected.
>> 2) TCP must be a valid default protocol.
>> 3) There may be a case for adding UDP to that set for RTTP.
>> 4) It should be capable of learning when a given client/server pair  
>> is blocked
>>   from using Transport X by some middle-box. Note: this is  
>> something a
>>   directory-based solution probably cannot do.,
>
> Yes, these seem reasonable to me, except generalize 2 and 3 with  
> something to the effect of:
>
> 	When negotiating a transport for a given application X, whatever  
> transport is normally the basic, "must-support" transport for  
> application X must be a valid default transport protocol.
>
> That means TCP must be a valid default protocol when negotiating a  
> transport for HTTP; UDP must be a valid default protocol when  
> negotiating a transport for RTTP; etc.
>
> Bryan
>

Agreed, that simplifies the rule and makes the intent clearer.

--
Caitlin Bestler
[e-mail]
http://www.asomi.com/CaitlinBestlerResume.html