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

Andrew Yourtchenko <ayourtch@cisco.com> Mon, 05 October 2009 17:51 UTC

Return-Path: <ayourtch@cisco.com>
X-Original-To: tae@core3.amsl.com
Delivered-To: tae@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C9D28C22F for <tae@core3.amsl.com>; Mon, 5 Oct 2009 10:51:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.775
X-Spam-Level:
X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfKhfu375Upu for <tae@core3.amsl.com>; Mon, 5 Oct 2009 10:51:00 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 082A33A699E for <tae@ietf.org>; Mon, 5 Oct 2009 10:50:57 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n95HqVlA009861; Mon, 5 Oct 2009 19:52:31 +0200 (CEST)
Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n95HqS4a014672; Mon, 5 Oct 2009 19:52:28 +0200 (CEST)
Date: Mon, 05 Oct 2009 12:52:31 +0200
From: Andrew Yourtchenko <ayourtch@cisco.com>
X-X-Sender: ayourtch@zippy.stdio.be
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4AC9F478.6080308@isi.edu>
Message-ID: <Pine.LNX.4.64.0910050850280.8462@zippy.stdio.be>
References: <Pine.LNX.4.64.0909180057060.5479@zippy.stdio.be> <77F0974F-62CD-411C-96D3-C29E6D872DEA@asomi.com> <Pine.LNX.4.64.0910010305520.3645@zippy.stdio.be> <4AC60448.2050507@isi.edu> <Pine.LNX.4.64.0910050457450.6309@zippy.stdio.be> <4AC9F478.6080308@isi.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: tae@ietf.org
Subject: Re: [tae] New draft: announcing the supported transports via DNS
X-BeenThere: tae@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ayourtch@cisco.com
List-Id: Transport Architecture Evolution <tae.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tae>, <mailto:tae-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tae>
List-Post: <mailto:tae@ietf.org>
List-Help: <mailto:tae-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tae>, <mailto:tae-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2009 17:51:02 -0000

On Mon, 5 Oct 2009, Joe Touch wrote:

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

This implies that these services would not work today with the dynamic 
address. Which is something understandable.

However, the item we were discussing was about forward DNS - for the case 
where one point wants to talk to the other point by name.

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

Yes, you indeed can fool the intermediate points.
http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-kaminsky/bh-us-04-kaminsky.ppt
But that's dangerous route.

>
> I'm also considering other issues - first-contact delay, fault
> tolerance, etc.

please bookmark this place [*]- I will reference it later.

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

DNS on a "shakey ISP" is not in the best interest of anyone. Besides, as I 
mentioned, this "shakey ISP" would already need to be used for determining 
name->address mapping.

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

Same as any other app. There will be endpoints that do not implement the 
transport selection, so they will assume whichever the legacy transport 
was.

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

per-application transport negotiation at the application layer ?

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

That's why I asked about the use cases, in the very beginning. I am 
suspecting I am talking about the use case that does involve the DNS,
and you talk about the use case that does not. Makes it hard to converge, 
I guess.

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

...which is the today's status quo. Every application runs on its 
transport. Where do we go from here ?

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

Here I will backreference the [*] - and quote your argument, which 
precisely coincides with mine about the new protocol:

> I'm also considering other issues - first-contact delay, fault
> tolerance, etc.

A) If we *start* with the new protocol, and it simply does not go through, we:

1) can not determine whether it was because the request was blocked or 
because the other end does not support this protocol.

2) still need to fallback to something that you know may work better.

B) Moreover, assuming we start the exchange on the new protocol in 
parallel with the "default fallback protocol", then either:

1) we still need to verify whether the negotiated protocol works (since 
the protocol negotiation protocol is a different one)

2) or we need to upfront use the inband negotiation within the protocol 
that the other end will speculatively support. Which we can not know 
because of the (A.1) above.

As I wrote earlier, "introducing new protocol" for a transport and
and "introducing new protocol" for the selection of new protocols for 
share a common subset of issues, the above is one of the examples.

What's your opininon ?

> (I see no need - or, as importantly, room, for doing this
> inside TCP SYN option space).

ok.

thanks,
andrew


>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAkrJ9HgACgkQE5f5cImnZrvZkgCfcpAWc0DT/uRyvZ/Db51Cn77b
> aLcAoO6kLdO8LAPrwynC47OJGIa9siCY
> =cKDO
> -----END PGP SIGNATURE-----
>