Subject: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 09 May 2017 19:27:01 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-core-coap-tcp-tls-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1) This draft removes the reliability and ordering features COAP when
used
over reliable transports, under the assumption that the transport will
provide. But the draft also includes the assumption that COAP proxies
exist.
This has the potential for creating a problem, since the transport can
only
provide guaranty reliable delivery and ordering to the next hop. Once
you
have a proxy in play, you loose that guaranty end to end.

This is further complicated because this draft contemplates
cross-transport
proxies, where one side may be over WebSocket (and I assume might be
over
TCP) and the other side over UDP. If the client sends via TCP but a
proxy
changes it to UDP, the client has no way to specify the reliability
properties to be used on the UDP connection. If one imagines a client
that uses
UDP to a forward proxy, which speaks TCP to a reverse-proxy, which then
switches back to UDP, any reliability properties specified by the client
will get
lost.

Also, a proxy can potentially reorder messages, even if it uses TCP on
both
sides. If one leaves ordering to the transport, then one needs to add
rules
about proxies maintaining that order.

2) It seems problematic to encode the transport choice in the URI
scheme.
 Section 7 says "They are hosted
in distinct namespaces because each URI scheme implies a distinct
origin
server." IIUC, this means any given resource can only be reached over a
specific transport. That seems to break the idea of cross-transport
proxies
as discussed in section 7.

It also does not seem to fit with a primary motivation for this draft.
That
is, one might want to use TCP because of local NAT/FW issues. But if
there is
a resource with a "coap" scheme, I cannot switch to TCP when I'm behind
a
problematic middlebox, and have an expectation of reaching the same
resource.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Subtantive:

3.2: I agree with Adam that this length scheme seems very complex for
the
return

3.3: Since the initiator can start sending messages before receiving a
CSM
from the responder, how long should the initiator wait for a CSM before
bailing?

3.4: Can you offer any guidance about how often to send keep-alives? I
note
that these keepalives are not necessarily bi-directional. Aren't there
some
NAT/FW cases where bi-directional traffic is needed to keep bindings
from
timing out?

This and other places explicitly mention that in-flight messages may be
lost
when the transport is closed or reset. This creates uncertainty about
whether
such messages have been processed or not. Is that really okay?

4: After the discussion resulting from Mark's Art-Art review, I expected
to
see more emphasis about WebSocket being intended for browser-based
clients.
There's a couple of in-passing mentions of browser-clients buried in
the
text; I would have expected something more up front.

4.2: Is it really worth making the framing code behave differently for
WebSocket than for TCP?

5.3: Do I understand correctly that once an option is established, it
cannot
be removed unless replaced? (Short of tearing down the connection and
starting over, anyway.)

7.2: The text mentions 443 as a default port, but really seems to make
5684
the default. If 443 is really a default, then this needs  discussion
about
why and why it's okay to squat on HTTPS.

The text about whether ALPN is required is confusing. Why not just
require
ALPN and move one, rather than special casing it by port choice? (There
seems
to be some circular logic about requiring 5685 to support clients that
don't
do ALPN, then saying clients MUST do ALPN unless they are using port
5685.)

7.3: I agree with Adam's DISCUSS comment. And even if people decide that
the
well-known bit can be specified in CORE, I think it does future users of
a
well-known URIs for ws a disservice to make them dig through this spec
to
find the update to 6455.  It would be better to pull that into a
separate
draft. That's also a material addition post IETF last call, so we should
consider
repeating the LC.

10.2: Is the registration policy "analogous to" that of [RFC7252] S12.2,
or
"identical to" it. If the answer is not "identical", then the policy
should be detailed here.

Editorial:

Figures 7 and 8: "Payload (if any)" - Can we assume that if one uses
either
extended length format, one has a payload?

3.3: Is the guidance about what errors to return if you don't implement
a
server any different here than for UDP?

4.3 and 4.4 seem to primarily repeat details that are the same for WS as
for
TCP, even though the introduction to the WS part says that it won't do
that
:-)

5.3: "One CSM MUST be sent by both endpoints...": s/both/each

7.6: The "updates" in this section are confusing. I understand this to
mean
that the procedures for TCP and WS are identical to those for UDP except
for
the mentioned steps. But the language of the form of "This step from
[RFC7252] is updated to:" makes it sound like this intends to actually
change
the language in 7252 to this new language. If the latter, then that
effectively removes UDP support from 7252 as updated.

This could easily be fixed by changing that to something to the effect
of
"When using TCP, this step changes to ..."

Appendix A: Why is this an appendix? Updates to a standards track RFC
seem to
warrant a more prominent position in the draft.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 May 2017 10:20:45 +0200

Hi Ben,

thank your for your review.

Before I start working on it in more detail, let me pick this one DISCUSS out because I think it is the most momentous issue that needs to be discussed:

> On May 10, 2017, at 04:27, Ben Campbell <[email-masked]> wrote:
> 

I would rephrase the issue as:
URIs don’t have a good place to put in transport hints.

(The definition of a transport hint in a URI would be information that lets me set up specific transports without creating a separate resource each time the values of that transport hint differ.)

Note that the main use case for the document at hand is one where the client may not be able to reach the server on the “main” transport (CoAP over UDP), so negotiation/upgrade(*) mechanisms are not solving the problem.

The solutions that people are talking about in our domain are about carrying transport alternatives around together.
E.g., see draft-silverajan-core-coap-protocol-negotiation-05.txt, which provides a way to find out about links from a set of links (the resource directory) while specifying a transport type. [It may be instructive to go through previous versions of this document just to see what we also have tried to do.]

What we have right now in draft-ietf-core-coap-tcp-tls is what we think is the least ugly way to solve the problem.
The WG is well aware about its problems.
We’d rather have a mechanism like transport hints, but we did not find a solution that would not need to update the web architecture.

Grüße, Carsten

(*) This is not an “upgrade” in the sense of going to a higher version of something in any case; it is just an alternative transport.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 May 2017 11:56:25 -0500

> On May 10, 2017, at 3:20 AM, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Ben,
> 

That’s exactly what I mean by “a primary motivation”. As defined, the name of a resource declares the transport. So if I have a “coap” scheme resource that I cannot reach over UDP, I cannot simply switch to TCP and reach that same resource, even if the server supports both UDP and TCP. I suppose the server could treat the two resources as aliases, but the client cannot know that without some out-of-band agreement. (but see next comment)

So is it expected that people have to decide in advance which transport will be use for any given resource? The middlebox-traversal use case would seem to favor approaches where the client gets to decide what transport to use on the fly.

> E.g., see draft-silverajan-core-coap-protocol-negotiation-05.txt, which provides a way to find out about links from a set of links (the resource directory) while specifying a transport type. [It ma…

So from an admittedly very quick scan, am I correct to assume that the directory described in that draft could be as “out-of-band” mechanism to declare resource aliases as I mentioned above? So why not use that sort of mechanism to advertise the available transports for an authority, and at least allow the transport selection to be completely decoupled from the scheme?

If people really want to bind transport selection to the resource name, then some such mechanism seems to be a requirement to make the solution in this draft fit for purpose. But the transport-negotiation draft is not yet adopted by CORE. Does it make sense to publish this before that is well on it’s way to ready?

> We’d rather have a mechanism like transport hints, but we did not find a solution that would not need to update the web architecture.

At least some other protocols do this with DNS NAPTR records. I realize that may not be realistic for constrained devices (and I gather the protocol-negotiation draft attacks that same problem.) SIP, for example, can specify the transport with a URI parameter, which allows a URI to either specify a transport or to be transport-independent (by leaving off the parameter.)

Thanks!

Ben.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 May 2017 20:54:13 +0200

> On May 10, 2017, at 18:56, Ben Campbell <[email-masked]> wrote:
> 
>> 

The way this is set up right now: Yes, the link tells you which transport to use.

> So from an admittedly very quick scan, am I correct to assume that the directory described in that draft could be as “out-of-band” mechanism to declare resource aliases as I mentioned above?

Well, you go from a directory search to a set of links, not as a way to go from one link to another.
Other sources of links (hypermedia documents) would also need to provide alternatives whenever they are needed.

> So why not use that sort of mechanism to advertise the available transports for an authority, and at least allow the transport selection to be completely decoupled from the scheme?

We weren’t sure whether we wanted to support the trend “to use this URI, you need this ancillary information”.
It would be nice if we could keep the URL property for our URIs.

> If people really want to bind transport selection to the resource name, then some such mechanism seems to be a requirement to make the solution in this draft fit for purpose. But the transport-nego…

Generally, we already know how to ship around sets of links.  What the transport-negotiation draft addresses is some additional functionality facilitating the bundling of these links in directories.  So coap-tcp-tls will be useful today for OMA and OCF, but we’d like to have the bundling available for the future.

> At least some other protocols do this with DNS NAPTR records. I realize that may not be realistic for constrained devices (and I gather the protocol-negotiation draft attacks that same problem.) SI…

Adding a level of indirection is not that useful in the constrained space — URIs are better if they are ready to use (many CoAP applications do not even use DNS).  Shipping around URIs that need additional lookup to use them is not so useful.  Having a multiple-transport URI that is compatible with (caches the same as) any of the single-transport ones would be great.  I’m not sure SIP transport parameters to that.

Grüße, Carsten

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 May 2017 21:00:55 -0500

> On May 10, 2017, at 1:54 PM, Carsten Bormann <[email-masked]> wrote:
> 
> 

I’m confused at how this mechanism addresses the middlebox problem it purports to solve. Is the server expected to know in advance whether all of the clients are behind UDP-eating middleboxes? What if a client moves back and forth from behind such a middlebox? 

And how are the cross-transport proxies described in this draft supposed to work at all, if a resource can only be reached over one transport?

> Other sources of links (hypermedia documents) would also need to provide alternatives whenever they are needed.

But do I understand correctly that with the transport negotiation draft, a server could advertise in such a directory that it was reachable over alternative transports? Wouldn’t that effectively mean that all of it’s resources are aliased for that alternative transport?

> Adding a level of indirection is not that useful in the constrained space — URIs are better if they are ready to use (many CoAP applications do not even use DNS).  Shipping around URIs that need ad…

For SIP URIs, two URIs with explicit transport parameters with different values do not match. But a SIP URI with a transport parameter matches an otherwise identical one with no transport parameter.

Thanks,

Ben.