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

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 1 Oct 2009 14:09:23 +0200 (CEST)

On Mon, 21 Sep 2009, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Caitlin Bestler wrote:
>>
>> On Sep 18, 2009, at 11:20 AM, Joe Touch wrote:
> ...
>>> As you note, addresses are sometimes used for non-human purposes, and
>>> with IPv6 they could be created on the fly - I wouldn't want to have to
>>> wait to register them in the DNS vs exchanging them in-band.
>>
>> Of course if you have already used application specific mechanisms to
>> exchange
>> IP addresses in-band then you obviously have the means to specify which
>> transport protocol and options to use as well.
>
> I could give you an IP address, and still want you to negotiate a
> transport you support with a transport that IP address supports. I can't
> know that answer, so it's not my business to specify the transport.
>
> Ultimately, either you're solving the transport discovery problem, or
> you're solving some other much more limited, DNS-focused case driven by
> a particular example. I'm not sure why that would be useful if you can
> solve the general case, but if so, it'd be important to explain that the
> 'applicability' of DNS-focused solutions.

I agree that a better view of the problem space is useful to see if 
we can arrive to a more generic solution - I made a first rough cut to it 
in my (overly long) mail to Caitlin, please feel free to amend.

thanks,
andrew

>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAkq3kQwACgkQE5f5cImnZrupagCdFO7Gc4iNmNGrkhrUoSIvX6pJ
> t+cAni6PaLP63Zrgo8uvrqgSKe7oJ5wv
> =fMso
> -----END PGP SIGNATURE-----
> _______________________________________________
> tae mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tae
>

---

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 1 Oct 2009 14:31:32 +0200 (CEST)

my 2 cents based also on reading of the exchange between Bryan, Dan and 
Caitlin inline:

On Sun, 20 Sep 2009, Michael Welzl wrote:

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

There are at least two possible scenarios I'd see:

a) default protocol is "selected" in case the peer simply does not have 
the support for the transport selection
b) the default protocol is "selected" after the fact because the more 
advanced protocol that was negotiated does not succeed.

and a worst case to consider is where the piggybacking on the existing 
"default" protocol breaks it - so there needs to be a fallback scenario 
for that case.

(a) is quite possible.
(b) very much not sure if possible.

>>  2) TCP must be a valid default protocol.
>>  3) There may be a case for adding UDP to that set for RTTP.

I'd phrase it something like: "There should always exist a valid 
fallback/default protocol that is defined on a per-application basis 
under the assumption that the transport selected is not implemented on 
the other endpoint".

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

+1. And the directory-based solution alone indeed can not do it. However, 
learning about the protocol being blocked, implies extra messages followed 
by a fallback to the "default" - the case of (1b) above.

I think it could be useful for first explicitly splitting the functions 
of "discovery" and "selection", and then seeing how they can be combined, 
if - a form of refactoring.

Having them originally split allows to focus on smaller chunks at a time, 
IMHO. When those chunks are well understood, it is easier to compose them.

thanks,
andrew

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Oct 2009 06:46:48 -0700

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

- - you're involving a third party in a two-party problem

- - you still have a bootstrapping problem -- by what transport do you
talk to the DNS?
	- if you solve that for DNS, why not use that solution at the
	endpoint?

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

Joe

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 5 Oct 2009 07:51:41 +0200 (CEST)

> ISP, and those ISPs don't offer the ability to register services with

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

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

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.

> It sounds like you've talked yourself out of using the DNS, or mostly

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Oct 2009 06:28:24 -0700

Andrew Yourtchenko wrote:
> 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.

> support on the nodes inbetween will influence the odds of being able to

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.

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

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

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 5 Oct 2009 10:45:44 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joe Touch
> Sent: Monday, October 05, 2009 6:28 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [tae] New draft: announcing the supported 
> transports via DNS
> 

Agreed.

But how is reverse DNS authentication relevant to selection of 
a transport protocol?

> a shakey ISP might not be in the best interest of the two 
> endpoints of a connection.

draft-wood-tae-specifying-uri-transports meets those 
requirements, at least as I understand what you have
described in this email.

> to the DNS, you have a default transport to talk to all other 
> endpoints anyway.

I sure would like to see your straw man proposal, because I
cannot fathom how you would accomplish this feat.

-d

> iEYEARECAAYFAkrJ9HgACgkQE5f5cImnZrvZkgCfcpAWc0DT/uRyvZ/Db51Cn77b
> aLcAoO6kLdO8LAPrwynC47OJGIa9siCY
> =cKDO

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 5 Oct 2009 12:52:31 +0200 (CEST)

> e.g., HTTP name-based access, SSL, etc. Users don't have control over

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.

> going on, and either try to help, block, or whatever, but they can be

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.

> tolerance, etc.

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

> Involving a DNS node on the other side of the planet in

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.

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

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

per-application transport negotiation at the application layer ?

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

> to the DNS, you have a default transport to talk to all other endpoints

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

> transports?

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

> 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

ok.

thanks,
andrew

---

From: Joe Touch <[email-masked]>
Date: Tue, 06 Oct 2009 09:42:23 -0700

Jumping down to the punchline:

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

True if you start with an existing protocol (e.g., TCP) and add an
option as well.

Agreed.

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

I agree.

IMO, this calls for a a protocol *between the endpoints* to determine
how to proceed. I don't think that fits or is appropriate for a TCP
option. I don't think the DNS is a useful protocol for this purpose
(whether between the endpoints or placed separately in the network).

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 06 Oct 2009 09:51:23 -0700

...
> But how is reverse DNS authentication relevant to selection of 

If all you have is an IP address (whether the user types it in or it is
provided in-band), the only thing you can lookup in the DNS (to find the
supported transports for that address) is reverse DNS.

...
> cannot fathom how you would accomplish this feat.

First, I don't need to provide a strawman to express concerns with an
existing proposal. We aren't picking a place for lunch*.

Second, I'm basically suggesting that this all boils down to the need
for a transport negotiation protocol between the endpoints. There are
numerous challenges to designing an effective negotiation protocol:

	- latency to detect supported protocols
	- latency to fallback if not supported
	- interaction with NATs/firewalls

Just saying "use the DNS" doesn't solve these problems any better than
"build a new exchange protocol", and adds other problems:

	- support for non-DNS endpoints (IP address specified)
	- involvement of a third party (lack of fate-sharing)

Joe

*(typical lunch location negotiation rules are "if you shoot down a
proposed site, you must counter with an alternative you are willing to
accept")

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 6 Oct 2009 10:55:41 -0700

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Tuesday, October 06, 2009 9:51 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]

Our proposal, draft-yourtchenko-tran-announce-dns-00, does
not suggest looking up PTR records.

We're trying to optimize the Happy Eyeballs probing
(draft-wing-http-new-tech-00) for the 99.65% of websites
that have DNS names.  99.65% comes from Alexa's list of
top 1,000,000 websites; 3455 of them are IPv4 address
literals.

-d

> iEYEARECAAYFAkrLdYsACgkQE5f5cImnZrvsjwCg5P6SGGzdxBwr2FtPr2aSPS/k
> Fa0AnjEmKD99tDni7QysjTpPDAeC/B4Z
> =+SUt