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

[Andrew Yourtchenko <[e-mail]>]

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

On Thu, 17 Sep 2009, 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, ...

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

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
> IP address of the server by application specific means.

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

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

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
>       where the connection/association should be established.
>

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