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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Andrew Yourtchenko wrote:
> 
> 
> On Fri, 2 Oct 2009, Joe Touch wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Some comments below...
>>
>> Andrew Yourtchenko wrote:
>> ...
>>> Also, if we assume "evil middlebox" in the middle, that decides to drop
>>> this new option, we will have a TCP connection that would not succeed,
>>> so then still there needs to be a fallback to "plain TCP".
>>>
>>> That's one of the rationales of bringing up the use of DNS in lieu of a
>>> in-band selection in general - we would still need to be able to
>>> fallback to probing in the worst case (how frequent is the worst case
>>> would of course need some more investigation).
>>
>> Use of the DNS is problematic on many levels:
>>
>> - - many users have IP addresses they don't control, e.g., assigned by an
>> ISP, and those ISPs don't offer the ability to register services with
>> their DNS
> 
> Use one of the dynamic DNS services. They exist and work well for the
> dynamic addresses. The ISP who assigns the IP has not much to do with
> the forward DNS resolution.

There are numerous applications that use reverse DNS for verification,
e.g., HTTP name-based access, SSL, etc. Users don't have control over
reverse DNS.

>> - - you're involving a third party in a two-party problem
> 
> It's not a two-party problem - at a minimum because the policy/protocol
> support on the nodes inbetween will influence the odds of being able to
> run a new transport.

Endpoints determine the meaning of a protocol. I can format messages
that look like UDP, and have the endpoints parse them as TCP if I want
- -- e.g., by having the endpoints interpret the transport protocol
numbers accordingly. Intermediate points can think they know what's
going on, and either try to help, block, or whatever, but they can be
fooled.

I'm also considering other issues - first-contact delay, fault
tolerance, etc. Involving a DNS node on the other side of the planet in
a shakey ISP might not be in the best interest of the two endpoints of a
connection.

>> - - you still have a bootstrapping problem -- by what transport do you
>> talk to the DNS?
> 
> I already know the addresses of the DNS servers. I know the default
> transport will work. 

Why? Why should DNS have a default transport?

I know my hosts's domain. Hence I can resolve the
> hostnames of my DNS servers. Hence I can lookup the transport record,
> and see if they offer something more, that I could try - keeping in mind
> that it is a suggestion and not an imperative. If it does not work I
> fall back onto using the default transport.

Hmm. So you can try a default to the DNS, and ask *it* for other
suggestions if it supports them.

Why isn't this good enough for the two endpoints as well?

>>     - if you solve that for DNS, why not use that solution at the
>>     endpoint?
>>
> 
> See above. It works, because the lowest common denominator is always
> available. So the DNS can work both for the "upgrade" of the DNS and on
> the endpoints for the suggestions about the new transports.

First, the DNS is not always available or desirable.

Second, if you solve this for the DNS, you can use a similar solution
directly between the endpoints without involving the DNS.

Third, if you force all endpoints to support a default transport to talk
to the DNS, you have a default transport to talk to all other endpoints
anyway.

...
>> It sounds like you've talked yourself out of using the DNS, or mostly
>> so. Is that the case?
> 
> No. What I am saying is that there is a place for both approaches.
> 
> In any case, would be interesting to know what constructive suggestions
> would you have on this topic ?
> 
> TCP option "let's kickstart a negotiation for a different protocol" ?

How about a SYN for a new protocol that has room for negotiating other
transports? (I see no need - or, as importantly, room, for doing this
inside TCP SYN option space).

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkrJ9HgACgkQE5f5cImnZrvZkgCfcpAWc0DT/uRyvZ/Db51Cn77b
aLcAoO6kLdO8LAPrwynC47OJGIa9siCY
=cKDO
-----END PGP SIGNATURE-----