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

[Andrew Yourtchenko <[e-mail]>]

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.

>
> - - 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.

>
> - - 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. 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.

> 	- 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.

>> Now, a few variables in discussion of selection via a separate protocol
>> vs. DNS-based.
>>
>> 1) neither actually proves the possibility of the new protocol to
>> traverse the middleboxes - so probing is needed for either case. The
>> policy enforcement points are (at least now) frequently decoupled from
>> the endpoints, so the probing would be needed regardless.
>>
>> 2) The separate protocol is more distinct than using a DNS record, so
>> requires a separate explicit policy decision and enforcement. (of course
>> the actual transport policy needs to be enforced separately for both).
>>
>> 3) If the DNS is used, then the failure to pass the particular DNS
>> record would mean we can'd do "advanced" transports - however, this does
>> not preclude from already starting on the "default" transport - since it
>> is not express a requirement, but a desire/proposal.
>> If we fail to get the reply using the separate protocol, then we need to
>> fallback to default, how do we do that ? (and for in-band negotiation
>> within transports, would it suffice to define a single method of
>> fallback ?)
>>
>> 4) Assuming the decisions re. the advertised transports are relatively
>> long-lived, in the case of DNS we should be able to benefit of
>> distributed caching, in case the cached replies do not fully correspond,
>> the fallback/probing that has to be there anyway, will help to with a
>> smoother fallback.
>>
>> 5) the caching nature of DNS, while providing a benefit, exposes one new
>> attack vector that I did not think of before - which is the
>> reconnaissance without the knowledge of the party that advertizes the
>> transports. The explicit protocol does not have such a property. This
>> may or may not be important.
>>
>> 6) Assuming the responder does not change its "default" graph
>> on a per-connection basis, it may be more beneficial to "pre-create" the
>> proposal and let the initiator do the work of creating the mutable
>> "common" graph - DNS might be more appropriate here. OTOH if the server
>> *needs* different graphs on a per-session basis, then a separate
>> protocol is more appropriate.
>>
>> 7) Introduction of the new protocol for negotiation of the new transport
>> protocols looks to be the same higher order function of "introducing a
>> new protocol", just with a different parameter.
>> The more distinctly "new" this protocol is, the more distinct this
>> property is. So maybe a combined, staged approach is something to consider.
>
> 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" ?

thanks,
andrew