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

From: Andrew Yourtchenko <[email-masked]>
Date: Fri, 18 Sep 2009 00:57:28 +0200 (CEST)

Hello all,

following the discussions at IETF75 on 
http://tools.ietf.org/html/draft-wing-http-new-tech-00, we have posted the 
an initial version of a "companion" draft that we think should help 
addressing some of the concerns:

http://www.ietf.org/id/draft-yourtchenko-tran-announce-dns-00.txt

Abstract:
While TCP has enjoyed many enhancements over the decades, it is
useful to allow applications to use transports beyond just UDP and
TCP and to use TCP in new ways.  It is inefficient to naively probe
the server using the new protocol.  This document proposes a new DNS
resource record which provides an efficient way to query which
protocols are supported by a server.

The comments are very much welcome.

thanks,
andrew

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 17 Sep 2009 17:31:41 -0700

On Sep 17, 2009, at 3:57 PM, Andrew Yourtchenko wrote:

> Hello all,
>
> following the discussions at IETF75 on http://tools.ietf.org/html/draft-wing-http-new-tech-00 
> , we have posted the an initial version of a "companion" draft that  
> we think should help addressing some of the concerns:
>

This looks like a solid starting point for a DNS-based solution.

The main problem I see is that the comma separated mechanism is  
probably insufficient to deal with the combination of
encryption protocols, transport protocols and special adaptations  
(RDMA, SCTP Partial Reliability, etc.) Something more
along the lines of a unique Java class name might be needed, with  
simple reserved names for the obvious: tcp, udp, sctp, ...

But more fundamentally I think there needs to be a discussion on the  
merits of various fundamental approaches. There
are at least three that I can think of:

* Extending a service discovery protocol, such as SLP.
* Extending DNS.
* One step protocol negotiation, presumably by identifying a new TCP  
option.

Some observations on using a Service Directory vs. DNS

It is indeed a service that is being looked up. Just because a host  
has SCTP does not meet that ULP X running
on that host knows how to use SCTP. Therefore these  entries are  
service specific. This can lead to an explosion
in DNS entries, especially if you have a multi-homed SCTP server that  
offers many traditional mini-serivces (echo,
time, etc.). If the DNS approach is used, allowing some form of  
wildcarding may be useful.

On the other hand, application developers seem to be hopelessly  
addicted to DNS.

The DNS approach will be challenged to deal with a service that is  
provided by a cluster of servers, especially
if some of the transports are only available on a portion of the  
servers.

The problem with any directory based solution is that it only works  
for registered services with names.
It does not encompass services that are advertised by other means  
where the application obtains the
IP address of the server by application specific means.

A one step protocol negotiation works for any client/server pair, and  
adds at most one extra step to
connection/association setup. It would work as follows:

1) client sends a lowest-common-denominator TCP-SYN with an option  
indicating the desire to
     use a set of alternate enhanced transports.
2a) If the server does not understand the option, it is not include in  
the SYN-ACK and a generic
        TCP connection is established.
2b) If the enhanced transport is still a TCP connection, the server  
responds with an option indicating
        the enchancements accepted.
2c) If the alternate transport selected is not TCP,  and the client  
indicated that it could receive requests
        on the alternate protocol, the server will initiate the  
alternate transport connection/association.
2d) If the alternate transport selected is not TCP, but the client  
must initiate, the TCP SYN ACK indicates
        where the connection/association should be established.

                      344344e\\\
\\]]0000000000000

---

From: Melinda Shore <[email-masked]>
Date: Thu, 17 Sep 2009 17:47:23 -0800

Caitlin Bestler wrote:
> The main problem I see is that the comma separated mechanism is probably 
> insufficient to deal with the combination of
> encryption protocols, transport protocols and special adaptations (RDMA, 
> SCTP Partial Reliability, etc.) Something more
> along the lines of a unique Java class name might be needed, with simple 
> reserved names for the obvious: tcp, udp, sctp, ...

I like structured namespaces but I think that an
hierarchical one might be overly limiting for something
like this, where future needs might not be possible
to anticipate.  I'm inclined to think that this is
one application for which a faceted classification/
namespace might be very well-suited.

I'm not crazy about adding yet more cruft to DNS,
either, but its advantage, which isn't trivial, is that
it doesn't require changes to other protocols and that
stuff that implements this approach is interoperable
with stuff that doesn't.  There also shouldn't be
performance impacts on the transport, nor would there
be ... firewall traversal impacts.

Melinda

---

From: Michael Welzl <[email-masked]>
Date: Fri, 18 Sep 2009 17:11:55 +0200

Hi all,

This discussion reminds me of something else:
someone (I think Jana?) mentioned the possibility of negotiating
more than just the transport protocol, e.g. even the usage of IPv6,
with a negotiation protocol.

I recently talked about this with someone who knows more about
IPv6 than me (actually not hard to find such a person!), and that
someone said that a standard is already in place for determining
whether IPv6 can be used **via DNS**.

So, whether or not the approach discussed here is adopted, for
the choice of IPv6 at least, DNS seems to be the way to go...
right? Opinions?

Cheers,
Michael

Melinda Shore schrieb:
> _______________________________________________
> tae mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tae

---

From: Joe Touch <[email-masked]>
Date: Fri, 18 Sep 2009 08:23:10 -0700

> whether IPv6 can be used **via DNS**.

That presumes two things:

a) you know which protocol to use to get to the DNS

b) not everybody uses the DNS, at which point you definitely need to
know the address format since you need to know the address

Joe

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 18 Sep 2009 08:28:15 -0700

> the choice of IPv6 at least, DNS seems to be the way to go...

I agree that we definitely should be making an attempt to be  
consistent with prior IETF decisions.

Choosing IPv6 vs IPV4 via DNS is a more natural fit than choosing  
between SCTP and TCP
because it is indeed a *host* that supports IPV6. Since most  
applications do not explicitly
bind their local address, or even examine the address of the remote  
peer, they will just use
IPV6 automatically if the host stack provides it. It is not a per- 
service decision.

The other precedent to examine is the determination of RPC protocol  
for NFS and other RPC
services. This was not done via DNS. I always found the resulting  
procedures awkward, but
that is something that there should be a group consensus on. If the  
final solution does not
follow the RPC strategy, it should explain the rationale for not doing  
so, and cite the experience
of people who have been working with RPC far more intensely than I have.

--------
Caitlin Bestler
[email-masked]
http://www.asomi.com/CaitlinBestlerResume.html

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Sep 2009 11:08:55 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joe Touch
> Sent: Friday, September 18, 2009 8:23 AM
> To: Michael Welzl
> Cc: [email-masked]
> Subject: Re: [tae] New draft: announcing the supported 
> transports via DNS
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Michael Welzl wrote:
> > Hi all,
> > 

Not everybody uses TCP, either.  For example, RTP is commonly
sent over UDP and the IPv4 addresses are commonly signaled in
SDP as IPv4 address literals.  So RTP doesn't use DNS or TCP.

But DNS-less and TCP-less applications or usage are not the
80% that is the interesting problem.  I can't maintain
host tables for the Internet anymore -- it's too big.  The need
for DNS is more acute with long and awkward IPv6 addresses.

-d

> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> 
> iEYEARECAAYFAkqzpd4ACgkQE5f5cImnZrv3ZQCg50PUZYlcFmLzGAUg8pG7Byve
> dEEAnjOhVyIijSZxzFnBfyIJ3qo4ghrq
> =FAka
> -----END PGP SIGNATURE-----

---

From: Joe Touch <[email-masked]>
Date: Fri, 18 Sep 2009 11:20:17 -0700

>> for DNS is more acute with long and awkward IPv6 addresses.

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.

JOe

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Sep 2009 11:35:48 -0700

> wait to register them in the DNS vs exchanging them in-band.

So, when you exchange them (in whatever application-specific protocol 
you're using to exchange those addresses, e.g., SDP for RTSP, SAP, 
and SIP) using that application-specific protocol is the best place 
to indicate which transport protocol is supported on the host.  This
is exactly how ICE extended SDP to allow indicating other transport
protocols, http://tools.ietf.org/html/draft-ietf-mmusic-ice-19.
The GROBJ BoF is where we're hoping to provide similar guidance to 
application developers who are referring IPv6/IPv4 addresses 
around.

Absent such an application-specific protocol to exchange addresses
we have the Internet's protocol to exchange addresses:  DNS.

-d

---

From: Joe Touch <[email-masked]>
Date: Fri, 18 Sep 2009 11:39:41 -0700

Dan Wing wrote:
> to indicate which transport protocol is supported on the host. 

I might want to say "here, use this address, but use whatever transport
the other end wants to use for reliable object transfer", which wouldn't
have the information available to the protocol that indicates the address.

> This

I don't want to use the DNS - I gave the other end an address, not a
name. The negotiation of how to talk between two endpoints is not an
endpoint alias issue - and the latter is what the DNS provides.

Joe

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Sep 2009 11:55:08 -0700

> I might want to say "here, use this address, but use whatever 
> transport the other end wants to use for reliable object 
> transfer", which wouldn't have the information available to 
> the protocol that indicates the address.

I don't understand; if you have an existing protocol to send
an IPv4 or IPv6 address around, it can be extended to include
a port (as most application developers have found necessary,
as we can't have more than one HTTP server listening on port
80 behind an in-home NAT), and it can likewise be extended to
say "TCP=yes, SCTP=yes, DCCP=no".

You're saying such an extension is not possible / reasonable?

> endpoint alias issue - and the latter is what the DNS provides.

I agree that protocols that exchange IP address literals should not,
and can not, use DNS.  My suggestion (above) for those protocols is
that the protocol that is carrying the IP address literal also 
carry which transport protocol is supported by the server, rather
than merely defaulting to UDP or defaulting to TCP.

I want to use DNS for protocols that are already using DNS.

I also don't want to use TCP to learn the transport protocol, 
because I may want to negotiate from UDP to DCCP, or negotiate
from UDP to SCTP.

Do you have a proposal you could share on the mailing list or
in an I-D?

-d

---

From: Joe Touch <[email-masked]>
Date: Fri, 18 Sep 2009 11:58:22 -0700

> say "TCP=yes, SCTP=yes, DCCP=no".

It can. Or it can be "here's an address and a port, you figure out what
transports are provided".

> You're saying such an extension is not possible / reasonable?

I'm saying it should not be strictly required.

> Do you have a proposal you could share on the mailing list or

No proposal; just trying to see if proposed solutions can handle cases I
consider useful.

Joe

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Sep 2009 12:07:06 -0700

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Friday, September 18, 2009 11:58 AM
> To: Dan Wing
> Cc: 'Michael Welzl'; [email-masked]
> It can. Or it can be "here's an address and a port, you 
> figure out what transports are provided".

Sure.  That's easy -- probe for whatever transport you want to
try.

The draft draft-yourtchenko-tran-announce-dns-00 is trying to
optimize that case.

In any event, probes are necessary because there may be middleboxes
that block certain transport protocols.

> I'm saying it should not be strictly required.

I agree.  

And it isn't required.

> No proposal; just trying to see if proposed solutions can 
> handle cases I consider useful.

Can you enumerate those requirements, or shall we just throw things at the
wall?  This goes back to Caitlin's post
<http://www.ietf.org/mail-archive/web/tae/current/msg00114.html> which
suggested we take a step back and look at what we want.  I'm all for doing
that.  This list has been too quiet, so we wrote a straw man.  I take it you
don't like the straw man because it's trying to cover the DNS use-case, and
your use-case is IP address literals, and your use-case can incur additional
round trip(s) to learn which transport protocols the server supports.

-d

> iEYEARECAAYFAkqz2E4ACgkQE5f5cImnZrs0LQCfePjjO8Fa7GYn627BH3pxn31b
> FOEAn2/DF1X8mkmWmrYrOKd3sQVAwtGl
> =0YqU

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 18 Sep 2009 12:19:54 -0700

> round trip(s) to learn which transport protocols the server supports.

Any non-directory based solution is going to run the risk of having an  
extra
message required to setup the connection/association. That suggests to  
me
that the solution set should include a directory based method, I'm  
just not sure
that DNS is appropriate for service-specific information.

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

--
Caitlin Bestler
[email-masked]

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 18 Sep 2009 13:23:46 -0700

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

That still leaves discovery via limited DNS, urls with literal IP  
addresses, discovery
by other administrative means and local discovery mechanisms such as  
zeroconf.

Does anyone know what impact DNS caches would have on a DNS based  
solution?
Are the entire set of DNS records for a domain routinely cached?

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Sep 2009 15:55:43 -0700

> From: Bryan Ford [mailto:[email-masked]] 
> Sent: Friday, September 18, 2009 1:58 PM
> To: Caitlin Bestler
> Cc: Dan Wing; [email-masked]; 'Joe Touch'
> On Sep 18, 2009, at 3:19 PM, Caitlin Bestler wrote:
> >> Can you enumerate those requirements, or shall we just 
> throw things  
> >> at the
> > Any non-directory based solution is going to run the risk 
> of having  
> > an extra
> > message required to setup the connection/association. That 
> suggests  
> > to me
> 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
> 
> Finally, one more point in favor of in-band over out-of-band 
> solution  
> is that you only need _one_ in-band solution,

No, you need two:  one for UDP upgraded to some-UDP-replacement,
and another for TCP upgraded to some-TCP-replacement.

I have seen ideas on this mailing list for how to do in-band with TCP (using
TCP options).  I haven't seen any ideas for how to do in-band with UDP;
perhaps because nobody cares about evolving UDP, or perhaps because there
isn't an in-band solution for UDP (I expect it's the latter).

-d

> 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?
> 
> > 4) It should be capable of learning when a given 
> client/server pair  
> > is blocked
> 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
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Sep 2009 16:01:16 -0700

> From: Caitlin Bestler [mailto:[email-masked]] 
> Sent: Friday, September 18, 2009 1:24 PM
> To: Joe Touch
> Cc: Dan Wing; [email-masked]
> > with IPv6 they could be created on the fly - I wouldn't 
> want to have  
> > to
> 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.
> 

Or we just shrug and don't optimize those cases.  I did a survey
of the top 1,000,000 domains on Alexa's list and about 2% have 
IPv4 address literals in their default page (e.g., an a=href
pointing to a URL with an IPv4 address literal in the hostname).
Also of Alexa's top 1,000,000 domains, 3455 were IPv4 address
literals, which is 0.35% of the top 1 million domains.  I don't
care much about optimizing for 0.35% of the Internet.  My 
interest is allowing SCTP to replace TCP, and allowing SCTP
and/or DCCP to replace UDP.  Optimizing this replacement so
we don't have to do zillions of Happy Eyeballs probes is 
valuable.

Alexa's list of websites can be obtained from the top right 
of http://www.alexa.com/topsites

-d

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 18 Sep 2009 16:40:07 -0700

On Sep 18, 2009, at 1:57 PM, Bryan Ford wrote:
> 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  

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.

> 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?
>
>> 4) It should be capable of learning when a given client/server pair  
>> is blocked
> 	When negotiating a transport for a given application X, whatever  

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

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 18 Sep 2009 16:50:53 -0700

> isn't an in-band solution for UDP (I expect it's the latter).

There is no simple solution for UDP because all possible UDP datagrams  
are
already legal. You cannot define a new meaning for a set of UDP  
datagrams
when those binary images are already legal to to transmit.

The closest you could come is having a reserved port number for the UDP
negotiation. Theoretically, your remote peer had no basis to send to  
that
port number anyway so can't really be upset that you have attached a
special meaning to all messages arriving on that port.

But such a solution would have the negative side-effect of cluttering up
UDP NATP tables in middle-boxes that don't know the special meaning
of the newly reserved port number.

---

From: Michael Welzl <[email-masked]>
Date: Sun, 20 Sep 2009 09:42:28 +0200

> 1) Must add no additional messages when the default protocol is selected.
>     from using Transport X by some middle-box. Note: this is something a

I agree with this list. It looks like a good starting point to me.

Cheers,
michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 21 Sep 2009 07:33:50 -0700

Dan Wing wrote:
...
>> suggested we take a step back and look at what we want. 

Caitlin's post considers a few candidate solutions, but doesn't explain
the requirements.

>> I'm all for doing

Any solution should be very clear about what it assumes already exists,
and what its limitations are. I would characterize the strawman as a
"assume the DNS" case. So any solution that uses the DNS needs to show
how the transport protocol used for the DNS is itself negotiated, and
needs to show how the solution applies when DNS names are not used by
the application.

My concern is that a DNS solution solves only the case where apps use
DNS names - and may have further limitations (what happens when a name
resolves to multiple IPs, and those IPs are on different machines and
support different transports?). If you have a non-DNS solution, it seems
like it would work for the DNS case.

So ultimately the question is "is a DNS-ony  solution a useful component
to an overall solution?" I'm struggling to see how.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 21 Sep 2009 07:43:25 -0700

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

Joe

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 21 Sep 2009 19:39:50 -0700

> 'applicability' of DNS-focused solutions.

The key requirement for the general case is that given the classic
minimums (remote peer IP and port number) how does a client connect
to the service using the optimum transport?

The starting point here is that serially attempting connections starting
with the 'best' transport, then the second best, etc. will not be  
acceptable.

For the specialized case where the two parties already have dynamically
exchanged information I see no reason why that application specific  
protocol
is not the best solution for efficiently exchanging the preferred-list- 
of-transports
information as well.

The applicability of a directory based solution is that when a  
directory is already
used to find the service, including the additional information would  
seem like
a no-brainer.

There are two major caveats to that, however:

a) Not all out-of-band exchanges are "directories", or at least  
extensible directories.
      One specific case that must be dealt with is a URL with a  
literal IP address.
       The URL is part of a web page, and as such any solution that  
requires modifying
       the web page as delivered based on local transport capabilities  
is probably
      unacceptable.
b) The proposed solution does not modify *the* "xyz.com" entry, but  
requires
      modifications/additions to "http.xyz.com", "ftp.xyz.com", "pop3.xyz.com 
", etc.
      Ideally the information on "the set of services I support with  
SCTP" would be
      listed under "xyz.com", but I suspect this is 20 lbs of potatoes  
in a 10 lb bag.

That leaves coming up with extensions of the current life-negotiations  
protocols
that add minimal overhead (and preferably none when the default  
protocol is
going to be selected anyway), are robust in the presence of  
selectively filtering
middleboxes and do not require rebuilding every Intrusion Detection  
System
already deployed.

Having "minimal overhead" and "looking normal to existing Intrusion  
Detection
Systems" is going to be a particular challenge.

---

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 1 Oct 2009 04:54:43 +0200 (CEST)

[apologies for the huge delay with the reply, catching up]

On Thu, 17 Sep 2009, Caitlin Bestler wrote:

> encryption protocols, transport protocols and special adaptations (RDMA, SCTP 
> Partial Reliability, etc.) Something more

One of the possibilities can be to use something along the lines of 
S-expressions, that should allow to represent directed acyclic graphs at 
the cost of some complexity.

(BTW, I think I owe here an apology to Bryan and Jana for forgetting to 
fill in the "[TBD]" in the Acknowledgements section with the reference to 
"An Efficient Cross-Layer Negotiation Protocol" paper).

More on the rationale "why (also) DNS" down in the end of the mail.

>
> But more fundamentally I think there needs to be a discussion on the merits 
> of various fundamental approaches. There
> * One step protocol negotiation, presumably by identifying a new TCP option.
>
>
> It is indeed a service that is being looked up. Just because a host has SCTP 
> does not meet that ULP X running
> on that host knows how to use SCTP. Therefore these  entries are service 
> specific. This can lead to an explosion
> in DNS entries, especially if you have a multi-homed SCTP server that offers 
> many traditional mini-serivces (echo,

I think I would not like to have this "work" for mini-services like echo - 
that's the one I'd normally use for low-level diagnostic purpose only (and 
in a public internet - only enable for a *very* short time, or put an ACL.
"time" is slightly different, but still it probably won't benefit too much 
of the alternative transport anyway. (And again, we're more in the 
diagnostic realm, and not in the 'publicly accessible service' realm.

> time, etc.). If the DNS approach is used, allowing some form of wildcarding 
> may be useful.

As we'd use the lookup of "applicationname.hostname" to look at what the 
other side can offer - indeed, would the "*.hostname" wildcard cover the 
needed functionality ? (as "multihomed" - I don't understand why this 
would matter - maybe you could clarify?)

>
> On the other hand, application developers seem to be hopelessly addicted to 
> DNS.
>
> The DNS approach will be challenged to deal with a service that is provided 
> by a cluster of servers, especially
> if some of the transports are only available on a portion of the servers.
>

yes, if this cluster serves the same hostname, indeed, that is a problem.
OTOH, the requirement to be "backwards compatible" and the need to cater 
for "the middleboxes that decide to be evil", should trigger the fallback 
mechanisms in this case ?

>
>
> The problem with any directory based solution is that it only works for 
> registered services with names.
> It does not encompass services that are advertised by other means where the 
> application obtains the

I would put the use cases along the spectrum with the following two ends:

1) This is a "foreign" party, unaware of the upcoming connection request.

2) This is a "friendly" party which is a part of multiparty protocol and 
is specifically awaiting for this connection request. In fact, maybe that 
we are already talking with this party.

I think the use case that Joe mentioned is closer to (2), and the draft 
concentrates heavily on (1).

The challenge I see with making this line continous is that at (1) end 
we inevitably have A/AAAA records, and at (2) we most probably don't want 
them (I think (2) is more or less the use case that Joe has mentioned).

This draft focuses largely on (1), where the support or non-support of 
particular transports is more of a policy decision. The host may even be 
able to accept the connections over transport Foo, but would prefer to not 
advertise it.

>
> A one step protocol negotiation works for any client/server pair, and adds at 
> most one extra step to
> 1) client sends a lowest-common-denominator TCP-SYN with an option indicating 
> the desire to

Though I suppose the bulk of the use-cases would be TCP, but this 
immediately excludes UDP. Is it something desirable ?

> 2a) If the server does not understand the option, it is not include in the 
> SYN-ACK and a generic
> 2b) If the enhanced transport is still a TCP connection, the server responds 
> with an option indicating
> 2c) If the alternate transport selected is not TCP,  and the client indicated 
> that it could receive requests
>      on the alternate protocol, the server will initiate the alternate 
> transport connection/association.

This would need to happen after the full three-way handshake, because 
otherwise an adversary can trigger both the DoS against a remote client 
and a resource exhaustion on the server by spoofing the SYN. So we will 
need to fully create the TCP connection and then abandon it.

> 2d) If the alternate transport selected is not TCP, but the client must 
> initiate, the TCP SYN ACK indicates

This may be useful, though due to the limited amount of TCP option space, 
how much would we really be able to squeeze into a TCP option in the 
SYN/ACK ? An option with just a single IPv6 address + protocol + port is 
2+16+1+2=21 bytes. This is rather expensive.

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

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.

kind regards,
andrew