Discussion:
[core] Artart last call review of draft-ietf-core-coap-tcp-tls-07
Mark Nottingham
2017-04-10 04:07:04 UTC
Permalink
Reviewer: Mark Nottingham
Review result: Not Ready

First, a general comment. I have been concerned about the duplication
of effort that COAP represents for some time, and that concern grows
significantly upon reading this draft. COAP is now specifying multiple
"bindings" to underlying application and transport protocols,
re-inventing message framing, congestion control in UDP, etc. The
introduction justifies this development over the reuse of HTTP/2 (and
presumably QUIC, once available) based upon the relative availability
of implementations for constrained devices. Whether that remains true
will only be judged by the market -- unfortunately after all of the
cost of development and standardisation is sunk.

The introduction motivates the layering of COAP over WebSockets to
allow it to be used in a network that only allows external access
through a HTTP proxy. In fact, it is not necessary to use WebSockets
to do so; HTTP CONNECT provides a tunnel in this scenario. WebSockets
is a specialised protocol that allows bidirectional, stream-based
transport from a Web browser -- it is effectively TCP wrapped into the
Web browser's security model, to make doing so safe. Using it for
other purposes (i.e., non-browser use cases) isn't really appropriate.
I'd suggest either removing the WebSockets binding, or changing its
motivation in the Introduction.

Section 7 defines a number of new URI schemes for COAP protocols.
Syntactically, they use "+" to separate "coap" from the underlying
transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This
syntax is allowed by RFC3986, but is unprecedented, and implies a
sub-syntax convention similar to those used in media types, etc. Is
there an expectation that other URI schemes starting with "coap+" are
reserved?

Defining URI schemes that switch transport protocol based upon their
name deserves wider review as well; this has been a contentious topic
in the past, and it would be good to understand what tradeoffs are
being made by doing so. Locking identifiers into a specific transport
protocol sacrifices much of the power of URLs. Furthermore, creating
"coap+ws" to denote a specific protocol over WebSockets (which has its
own URI scheme) is questionable; taken to its natural conclusion,
we'll have a proliferation of URI schemes for things over WebSockets.
Will COAP take the same approach for HTTP?

I would suggest a wider discussion of these issues on art@ / ***@.

Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://"
URI, using a well-known URI in the "wss" scheme. However, "wss" is not
defined to use well-known URIs, so this is an invalid use. I'm not
sure how to address this, other than removing the WebSockets binding.

Section 8.1 makes it Mandatory to Implement the protocol without any
security ("NoSec"). This seems counter to best practice in the IETF,
but I'll defer to the Security Area review.
Carsten Bormann
2017-04-10 09:46:40 UTC
Permalink
Hi Mark,

thank you for this thoughtful review.

This message will focus on a few technical points; I’ll leave aside the philosophical issues about whether the IETF should have a constrained node stack.
Post by Mark Nottingham
WebSockets
is a specialised protocol that allows bidirectional, stream-based
transport from a Web browser -- it is effectively TCP wrapped into the
Web browser's security model, to make doing so safe.
Indeed, that is the use case that was motivating this part.
Post by Mark Nottingham
Using it for
other purposes (i.e., non-browser use cases) isn't really appropriate.
I'd suggest either removing the WebSockets binding, or changing its
motivation in the Introduction.
I agree that the introduction should focus on the Browser use case and keep out of the firewall traversal jungle.
Post by Mark Nottingham
Section 7 defines a number of new URI schemes for COAP protocols.
Syntactically, they use "+" to separate "coap" from the underlying
transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This
syntax is allowed by RFC3986, but is unprecedented, and implies a
sub-syntax convention similar to those used in media types, etc. Is
there an expectation that other URI schemes starting with "coap+" are
reserved?
There is no such expectation.

We did have the discussion about reserved URI scheme prefixes in the IETF, and as I recall, the result was that there are none. While it would be a bit weird to register a URI scheme starting with coap+ or coaps+ that is unrelated to CoAP, only the slightly boggled response from an expert review is in the way of that happening.

Would the scheme names be more palatable with a dash instead of a plus?
Careful choice of the scheme name mostly benefits the implementer, so it can be changed in the spec (at the cost of changing existing implementations).
Post by Mark Nottingham
Defining URI schemes that switch transport protocol based upon their
name deserves wider review as well; this has been a contentious topic
in the past, and it would be good to understand what tradeoffs are
being made by doing so. Locking identifiers into a specific transport
protocol sacrifices much of the power of URLs.
The “siloing” of URIs along schemes is indeed a problem, which started for CoAP with the separation of the coap:/coaps: name spaces. The CoRE WG did not see it as its task to address this shortcoming. So, for now, we’ll have to live with it; approaches such as draft-silverajan-core-coap-protocol-negotiation are trying to address its practicalities.
Post by Mark Nottingham
Furthermore, creating
"coap+ws" to denote a specific protocol over WebSockets (which has its
own URI scheme) is questionable; taken to its natural conclusion,
we'll have a proliferation of URI schemes for things over WebSockets.
I’m not sure that a proliferation will happen — WebSockets is mostly used for tightly bound proprietary protocols between a JavaScript mobile code client and a server that provides this mobile code client. On the other hand, deciding to never use URIs to refer to resources available over a WebSockets protocol strikes me as an unnecessary restriction.
Post by Mark Nottingham
Will COAP take the same approach for HTTP?
Not sure what this question is leading into.
(We do have a defined relationship with HTTP, in RFC 7252 and RFC 8075.
But maybe this is about something different.)
Indeed, a wider discussion of these longstanding issues would be useful.
I’m not sure that waiting for their resolution is blocking this spec.
Post by Mark Nottingham
Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://"
URI, using a well-known URI in the "wss" scheme. However, "wss" is not
defined to use well-known URIs, so this is an invalid use.
This incorrect use of RFC 5785 is indeed embarrassing. More about that later.
Post by Mark Nottingham
Section 8.1 makes it Mandatory to Implement the protocol without any
security ("NoSec"). This seems counter to best practice in the IETF,
but I'll defer to the Security Area review.
Since it is the implementers who will decide whether they implement this, this co-author could live with making implementing NoSec completely optional. (It will be anyway, in practice, at the level of what is actually configured.) The important point(*) from the WG perspective here is that TLS is mandatory to implement, with the specifics depending on the security mode needed (cf. RFC 7925). (Note also that there are other ways to provide security with CoAP.)

Grüße, Carsten

(*) https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e9354242012afb28dc60
Mark Nottingham
2017-04-11 00:39:18 UTC
Permalink
Hi Carsten,

Couple of quic responses below.
Post by Carsten Bormann
I agree that the introduction should focus on the Browser use case and keep out of the firewall traversal jungle.
OK. Just curious -- is there a strong motivation here? It seems very odd to tunnel HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over HTTP again, rather than just using HTTP (which AIUI you already have a mapping to).
Post by Carsten Bormann
Post by Mark Nottingham
Section 7 defines a number of new URI schemes for COAP protocols.
Syntactically, they use "+" to separate "coap" from the underlying
transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This
syntax is allowed by RFC3986, but is unprecedented, and implies a
sub-syntax convention similar to those used in media types, etc. Is
there an expectation that other URI schemes starting with "coap+" are
reserved?
There is no such expectation.
We did have the discussion about reserved URI scheme prefixes in the IETF, and as I recall, the result was that there are none. While it would be a bit weird to register a URI scheme starting with coap+ or coaps+ that is unrelated to CoAP, only the slightly boggled response from an expert review is in the way of that happening.
Would the scheme names be more palatable with a dash instead of a plus?
Careful choice of the scheme name mostly benefits the implementer, so it can be changed in the spec (at the cost of changing existing implementations).
OK. I'm mostly noting this in case other folks feel that this is a bad precedent for URI schemes; I think the bigger concern is the one below.
Post by Carsten Bormann
Post by Mark Nottingham
Defining URI schemes that switch transport protocol based upon their
name deserves wider review as well; this has been a contentious topic
in the past, and it would be good to understand what tradeoffs are
being made by doing so. Locking identifiers into a specific transport
protocol sacrifices much of the power of URLs.
The “siloing” of URIs along schemes is indeed a problem, which started for CoAP with the separation of the coap:/coaps: name spaces. The CoRE WG did not see it as its task to address this shortcoming. So, for now, we’ll have to live with it; approaches such as draft-silverajan-core-coap-protocol-negotiation are trying to address its practicalities.
By defining multiple URI schemes for different transports of the same protocol, the WG has taken a position as to what the solution is. I'm finding it difficult to square this with the continuing characterisation of CORE as "RESTful".
Post by Carsten Bormann
Post by Mark Nottingham
Furthermore, creating
"coap+ws" to denote a specific protocol over WebSockets (which has its
own URI scheme) is questionable; taken to its natural conclusion,
we'll have a proliferation of URI schemes for things over WebSockets.
I’m not sure that a proliferation will happen — WebSockets is mostly used for tightly bound proprietary protocols between a JavaScript mobile code client and a server that provides this mobile code client. On the other hand, deciding to never use URIs to refer to resources available over a WebSockets protocol strikes me as an unnecessary restriction.
Post by Mark Nottingham
Will COAP take the same approach for HTTP?
Not sure what this question is leading into.
(We do have a defined relationship with HTTP, in RFC 7252 and RFC 8075.
But maybe this is about something different.)
I mean to ask whether there will be a need for a "coap+http" URI scheme; it seems like a logical conclusion of the approach taken here.
Post by Carsten Bormann
Indeed, a wider discussion of these longstanding issues would be useful.
I’m not sure that waiting for their resolution is blocking this spec.
Post by Mark Nottingham
Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://"
URI, using a well-known URI in the "wss" scheme. However, "wss" is not
defined to use well-known URIs, so this is an invalid use.
This incorrect use of RFC 5785 is indeed embarrassing. More about that later.
OK. The other obvious path is to opt wss:// (and ws://?) into RFC5785, but I think that would take a separate RFC that updates their scheme registrations. Not sure whether there would be any pushback in that community (but I can't see any immediate reason why there would be).
Post by Carsten Bormann
Post by Mark Nottingham
Section 8.1 makes it Mandatory to Implement the protocol without any
security ("NoSec"). This seems counter to best practice in the IETF,
but I'll defer to the Security Area review.
Since it is the implementers who will decide whether they implement this, this co-author could live with making implementing NoSec completely optional. (It will be anyway, in practice, at the level of what is actually configured.) The important point(*) from the WG perspective here is that TLS is mandatory to implement, with the specifics depending on the security mode needed (cf. RFC 7925). (Note also that there are other ways to provide security with CoAP.)
Ack. Again, this was mostly a note to bring it to others' attention; the use of the phrase "Mandatory to Implement" when applied to "no security" just seems odd.

Cheers,
Post by Carsten Bormann
Grüße, Carsten
(*) https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e9354242012afb28dc60
--
Mark Nottingham https://www.mnot.net/
weigengyu
2017-04-12 02:38:12 UTC
Permalink
Hi Mark,
Post by Mark Nottingham
OK. Just curious -- is there a strong motivation here?
It seems very odd to tunnel HTTP-like semantics over a custom UDP protocol
(COAP) over WebSockets over HTTP again,
rather than just using HTTP (which AIUI you already have a mapping to).
It is meaningful and interesting.
CoAP/UDP/IPv6 protocl stack can run well within CoRE environments.
But if CoAP/UDP is tried in the Internet, it will be blocked due to
NAT/firewall etcs based on tests done here a few years ago.
CoAP/TCP or CoAP/WSS could help CoAP messages and applications available
around Internet.

We have done some works about this topics.
The following are two abstracts of my master course students' theses, in
which may be interested.

THE RESEARCH AND DEVELOPMENT OF CoAP over TCP
ABSTRACT
The CoAP protocol is a restricted resource application protocol. In the CoAP
protocol research and application, the default CoAP protocol
stack use UDP as the transport layer。In the Ethernet environment, data
transmission will be affected because of the existence of the firewall .
For the reason that CoAP can be better applied to the current Internet
environment and cloud environment, IETF working group proposed CoAP over
TCP,
CoAP protocol stack use TCP as the transport layer .In this context, CoAP
over TCP is studied and CoAP over TCP is implemented based on the
open source framework Californium. The CoAP over TCP is implemented as a
client in the real Internet environment and the function of the
implementation is evaluated. CoAP over TCP is the Internet of Things cloud
platform services, so AWS environment is used to achieve CoAP over TLS/TCP
and the default protocol stack performance comparison.
In this paper, the significance of CoAP over TCP is expatiated, and CoAP
over TCP is studied. After that, the overall architecture of Californium
framework
is deeply analyzed, and the design scheme of CoAP over TCP is proposed. The
transport layer is extended on the basis of the original frame structure.
Based on the design scheme, the modules are designed and designed in detail.
On the core of the class through the class diagram describes the expansion
of the relationship between the various modules. The network layer, protocol
layer and application layer implementation process are analyzed in detail.
Afterwards, we study the proxy between CoAP over TCP and default protocol
stack, and propose the message type conversion problem and solution of
CoAPToCoAP proxy.
The paper concludes the relevant work, and puts forward the research
direction of the next step.
KEY WORDS: CoAP over TCP Proxy Californium Frame

THE DESIGN AND IMPLEMENTATION OF COAP OVER WEBSOCKET
ABSTRACT
The concept of Internet of Things (IoT) was originally proposed almost
twenty years ago. Over the past many years, IoT has gone through huge and
rapid development,
and the field of Wireless Sensor Network (WSN) has witnessed remarkable
advancement in particular. Compared to the progress of WSN, the practical
service
and application of IoT still has a very long way to go. Although current
industry standards can meet those equipments like smart phones, they are not
quite suitable
for constrained nodes which are often battery supported and has relatively
lower processing ability. Driven by such demands, the IETF set up CoRE
working group
to design a RESTful application protocol which can perform better among
constrained nodes in constrained environments.
The protocol was named Constrained Application Protocol (CoAP) and it was
later standardized as RFC 7252.
This paper analizes the features and defect of the HTTP/CoAP proxy proposed
in RFC 7252, and explains the CoAP over WebSocket proxy as well as its
advantages over
the HTTP/CoAP proxy. Then a design and implementation of CoAP over WebSocket
based on Californium open-source framework is given. Performance tests and
experiments have shown that the CoAP over WebSocket approach has some
significant advantages over HTTP/CoAP proxy in term of response time and
high concurrency
requests processing ability.
KEY WORDS: computer network, iot, coap, network proxy, websocket


Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Mark Nottingham
Sent: Tuesday, April 11, 2017 8:39 AM
To: Carsten Bormann
Cc: ***@ietf.org ; draft-ietf-core-coap-tcp-***@ietf.org ; ***@ietf.org
; ***@ietf.org
Subject: Re: [core] Artart last call review of
draft-ietf-core-coap-tcp-tls-07

Hi Carsten,

Couple of quic responses below.
Post by Mark Nottingham
I agree that the introduction should focus on the Browser use case and
keep out of the firewall traversal jungle.
OK. Just curious -- is there a strong motivation here? It seems very odd to
tunnel HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets
over HTTP again, rather than just using HTTP (which AIUI you already have a
mapping to).
Post by Mark Nottingham
Post by Mark Nottingham
Section 7 defines a number of new URI schemes for COAP protocols.
Syntactically, they use "+" to separate "coap" from the underlying
transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This
syntax is allowed by RFC3986, but is unprecedented, and implies a
sub-syntax convention similar to those used in media types, etc. Is
there an expectation that other URI schemes starting with "coap+" are
reserved?
There is no such expectation.
We did have the discussion about reserved URI scheme prefixes in the IETF,
and as I recall, the result was that there are none. While it would be a
bit weird to register a URI scheme starting with coap+ or coaps+ that is
unrelated to CoAP, only the slightly boggled response from an expert
review is in the way of that happening.
Would the scheme names be more palatable with a dash instead of a plus?
Careful choice of the scheme name mostly benefits the implementer, so it
can be changed in the spec (at the cost of changing existing
implementations).
OK. I'm mostly noting this in case other folks feel that this is a bad
precedent for URI schemes; I think the bigger concern is the one below.
Post by Mark Nottingham
Post by Mark Nottingham
Defining URI schemes that switch transport protocol based upon their
name deserves wider review as well; this has been a contentious topic
in the past, and it would be good to understand what tradeoffs are
being made by doing so. Locking identifiers into a specific transport
protocol sacrifices much of the power of URLs.
The “siloing” of URIs along schemes is indeed a problem, which started
for CoAP with the separation of the coap:/coaps: name spaces. The CoRE WG
did not see it as its task to address this shortcoming. So, for now, we’ll
have to live with it; approaches such as
draft-silverajan-core-coap-protocol-negotiation are trying to address its
practicalities.
By defining multiple URI schemes for different transports of the same
protocol, the WG has taken a position as to what the solution is. I'm
finding it difficult to square this with the continuing characterisation of
CORE as "RESTful".
Post by Mark Nottingham
Post by Mark Nottingham
Furthermore, creating
"coap+ws" to denote a specific protocol over WebSockets (which has its
own URI scheme) is questionable; taken to its natural conclusion,
we'll have a proliferation of URI schemes for things over WebSockets.
I’m not sure that a proliferation will happen — WebSockets is mostly
used for tightly bound proprietary protocols between a JavaScript mobile
code client and a server that provides this mobile code client. On the
other hand, deciding to never use URIs to refer to resources available
over a WebSockets protocol strikes me as an unnecessary restriction.
Post by Mark Nottingham
Will COAP take the same approach for HTTP?
Not sure what this question is leading into.
(We do have a defined relationship with HTTP, in RFC 7252 and RFC 8075.
But maybe this is about something different.)
I mean to ask whether there will be a need for a "coap+http" URI scheme; it
seems like a logical conclusion of the approach taken here.
Post by Mark Nottingham
Indeed, a wider discussion of these longstanding issues would be useful.
I’m not sure that waiting for their resolution is blocking this spec.
Post by Mark Nottingham
Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://"
URI, using a well-known URI in the "wss" scheme. However, "wss" is not
defined to use well-known URIs, so this is an invalid use.
This incorrect use of RFC 5785 is indeed embarrassing. More about that later.
OK. The other obvious path is to opt wss:// (and ws://?) into RFC5785, but I
think that would take a separate RFC that updates their scheme
registrations. Not sure whether there would be any pushback in that
community (but I can't see any immediate reason why there would be).
Post by Mark Nottingham
Post by Mark Nottingham
Section 8.1 makes it Mandatory to Implement the protocol without any
security ("NoSec"). This seems counter to best practice in the IETF,
but I'll defer to the Security Area review.
Since it is the implementers who will decide whether they implement this,
this co-author could live with making implementing NoSec completely
optional. (It will be anyway, in practice, at the level of what is
actually configured.) The important point(*) from the WG perspective here
is that TLS is mandatory to implement, with the specifics depending on the
security mode needed (cf. RFC 7925). (Note also that there are other ways
to provide security with CoAP.)
Ack. Again, this was mostly a note to bring it to others' attention; the use
of the phrase "Mandatory to Implement" when applied to "no security" just
seems odd.

Cheers,
Post by Mark Nottingham
Grüße, Carsten
(*)
https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e9354242012afb28dc60
--
Mark Nottingham https://www.mnot.net/

_______________________________________________
core mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/core
Mark Nottingham
2017-04-12 02:42:16 UTC
Permalink
So, is COAP using WebSockets for browser access, or for firewall traversal? The paper below seems to indicate the latter, and so the original question remains.

Also, the assertions about firewalls are interesting; we're hearing very different assertions in the discussions of QUIC (e.g,. 90%+ success rates for UDP protocols).

Cheers,
Post by Carsten Bormann
Hi Mark,
Post by Mark Nottingham
OK. Just curious -- is there a strong motivation here?
It seems very odd to tunnel HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over HTTP again,
rather than just using HTTP (which AIUI you already have a mapping to).
It is meaningful and interesting.
CoAP/UDP/IPv6 protocl stack can run well within CoRE environments.
But if CoAP/UDP is tried in the Internet, it will be blocked due to NAT/firewall etcs based on tests done here a few years ago.
CoAP/TCP or CoAP/WSS could help CoAP messages and applications available around Internet.
We have done some works about this topics.
The following are two abstracts of my master course students' theses, in which may be interested.
THE RESEARCH AND DEVELOPMENT OF CoAP over TCP
ABSTRACT
The CoAP protocol is a restricted resource application protocol. In the CoAP protocol research and application, the default CoAP protocol
stack use UDP as the transport layer。In the Ethernet environment, data transmission will be affected because of the existence of the firewall .
For the reason that CoAP can be better applied to the current Internet environment and cloud environment, IETF working group proposed CoAP over TCP,
CoAP protocol stack use TCP as the transport layer .In this context, CoAP over TCP is studied and CoAP over TCP is implemented based on the
open source framework Californium. The CoAP over TCP is implemented as a client in the real Internet environment and the function of the
implementation is evaluated. CoAP over TCP is the Internet of Things cloud platform services, so AWS environment is used to achieve CoAP over TLS/TCP
and the default protocol stack performance comparison.
In this paper, the significance of CoAP over TCP is expatiated, and CoAP over TCP is studied. After that, the overall architecture of Californium framework
is deeply analyzed, and the design scheme of CoAP over TCP is proposed. The transport layer is extended on the basis of the original frame structure.
Based on the design scheme, the modules are designed and designed in detail. On the core of the class through the class diagram describes the expansion
of the relationship between the various modules. The network layer, protocol layer and application layer implementation process are analyzed in detail.
Afterwards, we study the proxy between CoAP over TCP and default protocol stack, and propose the message type conversion problem and solution of CoAPToCoAP proxy.
The paper concludes the relevant work, and puts forward the research direction of the next step.
KEY WORDS: CoAP over TCP Proxy Californium Frame
THE DESIGN AND IMPLEMENTATION OF COAP OVER WEBSOCKET
ABSTRACT
The concept of Internet of Things (IoT) was originally proposed almost twenty years ago. Over the past many years, IoT has gone through huge and rapid development,
and the field of Wireless Sensor Network (WSN) has witnessed remarkable advancement in particular. Compared to the progress of WSN, the practical service
and application of IoT still has a very long way to go. Although current industry standards can meet those equipments like smart phones, they are not quite suitable
for constrained nodes which are often battery supported and has relatively lower processing ability. Driven by such demands, the IETF set up CoRE working group
to design a RESTful application protocol which can perform better among constrained nodes in constrained environments.
The protocol was named Constrained Application Protocol (CoAP) and it was later standardized as RFC 7252.
This paper analizes the features and defect of the HTTP/CoAP proxy proposed in RFC 7252, and explains the CoAP over WebSocket proxy as well as its advantages over
the HTTP/CoAP proxy. Then a design and implementation of CoAP over WebSocket based on Californium open-source framework is given. Performance tests and
experiments have shown that the CoAP over WebSocket approach has some significant advantages over HTTP/CoAP proxy in term of response time and high concurrency
requests processing ability.
KEY WORDS: computer network, iot, coap, network proxy, websocket
Regards,
Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- From: Mark Nottingham
Sent: Tuesday, April 11, 2017 8:39 AM
To: Carsten Bormann
Subject: Re: [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07
Hi Carsten,
Couple of quic responses below.
Post by Mark Nottingham
I agree that the introduction should focus on the Browser use case and keep out of the firewall traversal jungle.
OK. Just curious -- is there a strong motivation here? It seems very odd to tunnel HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over HTTP again, rather than just using HTTP (which AIUI you already have a mapping to).
Post by Mark Nottingham
Post by Mark Nottingham
Section 7 defines a number of new URI schemes for COAP protocols.
Syntactically, they use "+" to separate "coap" from the underlying
transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This
syntax is allowed by RFC3986, but is unprecedented, and implies a
sub-syntax convention similar to those used in media types, etc. Is
there an expectation that other URI schemes starting with "coap+" are
reserved?
There is no such expectation.
We did have the discussion about reserved URI scheme prefixes in the IETF, and as I recall, the result was that there are none. While it would be a bit weird to register a URI scheme starting with coap+ or coaps+ that is unrelated to CoAP, only the slightly boggled response from an expert review is in the way of that happening.
Would the scheme names be more palatable with a dash instead of a plus?
Careful choice of the scheme name mostly benefits the implementer, so it can be changed in the spec (at the cost of changing existing implementations).
OK. I'm mostly noting this in case other folks feel that this is a bad precedent for URI schemes; I think the bigger concern is the one below.
Post by Mark Nottingham
Post by Mark Nottingham
Defining URI schemes that switch transport protocol based upon their
name deserves wider review as well; this has been a contentious topic
in the past, and it would be good to understand what tradeoffs are
being made by doing so. Locking identifiers into a specific transport
protocol sacrifices much of the power of URLs.
The “siloing” of URIs along schemes is indeed a problem, which started for CoAP with the separation of the coap:/coaps: name spaces. The CoRE WG did not see it as its task to address this shortcoming. So, for now, we’ll have to live with it; approaches such as draft-silverajan-core-coap-protocol-negotiation are trying to address its practicalities.
By defining multiple URI schemes for different transports of the same protocol, the WG has taken a position as to what the solution is. I'm finding it difficult to square this with the continuing characterisation of CORE as "RESTful".
Post by Mark Nottingham
Post by Mark Nottingham
Furthermore, creating
"coap+ws" to denote a specific protocol over WebSockets (which has its
own URI scheme) is questionable; taken to its natural conclusion,
we'll have a proliferation of URI schemes for things over WebSockets.
I’m not sure that a proliferation will happen — WebSockets is mostly used for tightly bound proprietary protocols between a JavaScript mobile code client and a server that provides this mobile code client. On the other hand, deciding to never use URIs to refer to resources available over a WebSockets protocol strikes me as an unnecessary restriction.
Post by Mark Nottingham
Will COAP take the same approach for HTTP?
Not sure what this question is leading into.
(We do have a defined relationship with HTTP, in RFC 7252 and RFC 8075.
But maybe this is about something different.)
I mean to ask whether there will be a need for a "coap+http" URI scheme; it seems like a logical conclusion of the approach taken here.
Post by Mark Nottingham
Indeed, a wider discussion of these longstanding issues would be useful.
I’m not sure that waiting for their resolution is blocking this spec.
Post by Mark Nottingham
Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://"
URI, using a well-known URI in the "wss" scheme. However, "wss" is not
defined to use well-known URIs, so this is an invalid use.
This incorrect use of RFC 5785 is indeed embarrassing. More about that later.
OK. The other obvious path is to opt wss:// (and ws://?) into RFC5785, but I think that would take a separate RFC that updates their scheme registrations. Not sure whether there would be any pushback in that community (but I can't see any immediate reason why there would be).
Post by Mark Nottingham
Post by Mark Nottingham
Section 8.1 makes it Mandatory to Implement the protocol without any
security ("NoSec"). This seems counter to best practice in the IETF,
but I'll defer to the Security Area review.
Since it is the implementers who will decide whether they implement this, this co-author could live with making implementing NoSec completely optional. (It will be anyway, in practice, at the level of what is actually configured.) The important point(*) from the WG perspective here is that TLS is mandatory to implement, with the specifics depending on the security mode needed (cf. RFC 7925). (Note also that there are other ways to provide security with CoAP.)
Ack. Again, this was mostly a note to bring it to others' attention; the use of the phrase "Mandatory to Implement" when applied to "no security" just seems odd.
Cheers,
Post by Mark Nottingham
Grüße, Carsten
(*) https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e9354242012afb28dc60
--
Mark Nottingham https://www.mnot.net/
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
--
Mark Nottingham https://www.mnot.net/
Carsten Bormann
2017-04-12 04:04:33 UTC
Permalink
Post by Mark Nottingham
So, is COAP using WebSockets for browser access, or for firewall traversal? The paper below seems to indicate the latter, and so the original question remains.
Can’t answer that for Gengyu, but the term “firewall” occurs in the CoAP over TCP abstract, not in the CoAP over WebSockets one.

I continue to maintain that for CoAP over WebSockets the access to CoAP proxies from browsers is the motivating case. (Yes, these could also be HTTP to CoAP cross-protocol proxies, but there are impedance mismatches here; e.g., for a browser application that wants to observe a CoAP resource.)
Post by Mark Nottingham
Also, the assertions about firewalls are interesting; we're hearing very different assertions in the discussions of QUIC (e.g,. 90%+ success rates for UDP protocols).
Apart from the backend motivation, the main motivation for CoAP over TCP was easier NAT traversal (UDP bindings are timed out much faster in most NATs). This may extend to other middleboxes, including firewalls that build (and then time out) UDP-based state.

I’m not sure the QUIC numbers transfer to this use case very well, as QUIC is mostly used for web page access from browsers, so short NAT binding timeouts don’t matter that much. For a sensor that needs to be accessed every 30 minutes, these are much more of an issue.

Grüße, Carsten
Bill Silverajan
2017-04-12 10:53:05 UTC
Permalink
Hello,
Post by Carsten Bormann
Post by Mark Nottingham
So, is COAP using WebSockets for browser access, or for firewall traversal? The paper below seems to indicate the latter, and so the original question remains.
Can’t answer that for Gengyu, but the term “firewall” occurs in the CoAP over TCP abstract, not in the CoAP over WebSockets one.
I continue to maintain that for CoAP over WebSockets the access to CoAP proxies from browsers is the motivating case. (Yes, these could also be HTTP to CoAP cross-protocol proxies, but there are impedance mismatches here; e.g., for a browser application that wants to observe a CoAP resource.)
Carsten's right. The primary use case which motivated us to undertake
the work were for browser access, and for sandboxed web applications
that want to use CoAP-based communication to a end-point, but are
restricted from using system-level APIs such as TCP or UDP socket
libraries. Matthias (in a forked version of this message thread) also
mentioned where we saw benefits in allowing CoAP over Websockets to
reach constrained devices.

While the work was progressing however, we did become aware of minor use
cases where using CoAP over Websockets can provide an advantage:
Reaching constrained nodes residing in domains where end users may lack
the authority to configure middleboxes to allow new services over
TCP/UDP. This is commonplace in particularly restrictive and firewalled
networks that otherwise allow traditional messaging, email and web-based
services. However, I need to emphasise this is a minor use case.

Best regards,
Bill
Jaime Jiménez
2017-04-13 14:47:00 UTC
Permalink
Hi,

could you share data source on that pls? It’d come in handy.

Ciao!
- - Jaime Jiménez

On 12 Apr 2017, at 5.42, Mark Nottingham <***@mnot.net<mailto:***@mnot.net>> wrote:

(e.g,. 90%+ success rates for UDP protocols).
Kovatsch Matthias
2017-04-12 09:51:38 UTC
Permalink
Dear Mark
Post by Mark Nottingham
OK. Just curious -- is there a strong motivation here? It seems very odd to tunnel
HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over
HTTP again, rather than just using HTTP (which AIUI you already have a mapping
to).
The motivation is to connect the constrained environment to the Web browser. Ideally, one would use HTTP from the browser to talk to a HTTP-CoAP cross-proxy, which in turn talks to the constrained device. The problem here is that HTTP never properly and uniquely solved server push, which is quite crucial for resource-constrained devices and IoT use cases. Thus---even beyond the CoRE use case---people resort to WebSockets. Since WebSockets are just a browser version of TCP, people also have to invent their own protocol every time... This is where CoAP-over-WebSockets helps, of course with the primary focus to seamlessly connect to constrained devices.

I am not sure what is the preferred way to solve the async communication issue of HTTP. Server Sent Events, for instance, are already pretty close to the Observe mechanism. Maybe we could properly fix the push support of HTTP to counter the endless stacking of protocols a bit?

Best regards
Matthias
Alexey Melnikov
2017-04-12 10:06:06 UTC
Permalink
Hi Matthias,
Post by Kovatsch Matthias
Dear Mark
Post by Mark Nottingham
OK. Just curious -- is there a strong motivation here? It seems very odd to tunnel
HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over
HTTP again, rather than just using HTTP (which AIUI you already have a mapping
to).
The motivation is to connect the constrained environment to the Web browser. Ideally, one would use HTTP from the browser to talk to a HTTP-CoAP cross-proxy, which in turn talks to the constrained device. The problem here is that HTTP never properly and uniquely solved server push, which is quite crucial for resource-constrained devices and IoT use cases. Thus---even beyond the CoRE use case---people resort to WebSockets. Since WebSockets are just a browser version of TCP, people also have to invent their own protocol every time... This is where CoAP-over-WebSockets helps, of course with the primary focus to seamlessly connect to constrained devices.
I am not sure what is the preferred way to solve the async communication issue of HTTP. Server Sent Events, for instance, are already pretty close to the Observe mechanism. Maybe we could properly fix the push support of HTTP to counter the endless stacking of protocols a bit?
We have a WG for this:
https://datatracker.ietf.org/wg/webpush/about/
Mark Nottingham
2017-04-12 10:09:21 UTC
Permalink
[ cutting down the CC a bit ]
Post by Alexey Melnikov
Hi Matthias,
Post by Kovatsch Matthias
Dear Mark
Post by Mark Nottingham
OK. Just curious -- is there a strong motivation here? It seems very odd to tunnel
HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets over
HTTP again, rather than just using HTTP (which AIUI you already have a mapping
to).
The motivation is to connect the constrained environment to the Web browser. Ideally, one would use HTTP from the browser to talk to a HTTP-CoAP cross-proxy, which in turn talks to the constrained device. The problem here is that HTTP never properly and uniquely solved server push, which is quite crucial for resource-constrained devices and IoT use cases. Thus---even beyond the CoRE use case---people resort to WebSockets. Since WebSockets are just a browser version of TCP, people also have to invent their own protocol every time... This is where CoAP-over-WebSockets helps, of course with the primary focus to seamlessly connect to constrained devices.
I am not sure what is the preferred way to solve the async communication issue of HTTP. Server Sent Events, for instance, are already pretty close to the Observe mechanism. Maybe we could properly fix the push support of HTTP to counter the endless stacking of protocols a bit?
https://datatracker.ietf.org/wg/webpush/about/
Well, yes and no. My understanding is that web push is designed for a very specific use case / deployment scenario, and it is likely not appropriate for other uses.



--
Mark Nottingham https://www.mnot.net/
Kovatsch Matthias
2017-04-12 10:16:56 UTC
Permalink
Post by Kovatsch Matthias
Post by Alexey Melnikov
Post by Kovatsch Matthias
I am not sure what is the preferred way to solve the async communication
issue of HTTP. Server Sent Events, for instance, are already pretty close to the
Observe mechanism. Maybe we could properly fix the push support of HTTP to
counter the endless stacking of protocols a bit?
Post by Alexey Melnikov
https://datatracker.ietf.org/wg/webpush/about/
Well, yes and no. My understanding is that web push is designed for a very
specific use case / deployment scenario, and it is likely not appropriate for other
uses.
This is also my conclusion about this variant of HTTP push.

Best wishes
Matthias
Kovatsch, Matthias
2017-04-19 17:58:53 UTC
Permalink
Hi there

I am picking up this discussion again, as I was made aware of another use case for CoAP-over-WebSockets related to firewalls or shielded networks: without having looked into the details, HTTP CONNECT apparently does not allow for OAuth, while upgrading to WebSockets can make use of OAuth to establish a secure channel between two edge CoAP proxies that, for instance, forward requests from devices behind one firewall to devices behind another firewall.

Best wishes
Matthias
Carsten Bormann
2017-04-19 19:10:31 UTC
Permalink
Hi Matthias,

while I can imagine uses cases like that, I don’t believe that a specification has to be exhaustive in listing its use cases. The CoAP over WebSockets work was motivated by getting full CoAP functionality into a browser by providing a way for JavaScript code to use a proxy, and maybe it is enough to point this out in the specification. I don’t think it is expedient to add use cases that tend to press unrelated buttons in people — even if they are made possible by the generality of the specification. Implementers will find out anyway...

Grüße, Carsten
Post by Kovatsch, Matthias
Hi there
I am picking up this discussion again, as I was made aware of another use case for CoAP-over-WebSockets related to firewalls or shielded networks: without having looked into the details, HTTP CONNECT apparently does not allow for OAuth, while upgrading to WebSockets can make use of OAuth to establish a secure channel between two edge CoAP proxies that, for instance, forward requests from devices behind one firewall to devices behind another firewall.
Best wishes
Matthias
_______________________________________________
art mailing list
https://www.ietf.org/mailman/listinfo/art
Brian Raymor
2017-04-19 00:48:17 UTC
Permalink
Thanks for your thoughtful feedback, Mark.
Post by Carsten Bormann
Post by Mark Nottingham
Section 8.1 makes it Mandatory to Implement the protocol without any
security ("NoSec"). This seems counter to best practice in the IETF,
but I'll defer to the Security Area review.
Since it is the implementers who will decide whether they implement this, this co-author could live with making implementing NoSec
completely optional. (It will be anyway, in practice, at the level of what is actually configured.) The important point(*) from the WG
perspective here is that TLS is mandatory to implement, with the specifics depending on the security mode needed (cf. RFC 7925).
(Note also that there are other ways to provide security with CoAP.)
(*) https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e9354242012afb28dc60
Some context - during the security discussions in the WG, there was a recommendation to "mirror" the similar section in RFC7252.

https://tools.ietf.org/html/rfc7252#section-9 states:

The NoSec and RawPublicKey modes are mandatory to implement for this specification.

which is why NoSec is MTI.

I agree with Carsten. I'd be happy to make this completely optional if it results in less dissonance for reviewers and there are no objections in the WG.
Mark Nottingham
2017-05-09 21:30:35 UTC
Permalink
Post by Carsten Bormann
Post by Mark Nottingham
Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://"
URI, using a well-known URI in the "wss" scheme. However, "wss" is not
defined to use well-known URIs, so this is an invalid use.
This incorrect use of RFC 5785 is indeed embarrassing. More about that later.
To close this loop -- the change in -08 isn't sufficiently prominent IME; while the general nature of the change is listed in the Abstract, the actual normative text is very hard to find. Given that this is a pretty fundamental change in the operation of a URI scheme, I'd think it at least deserves its own section, if not a separate document.

Cheers,

--
Mark Nottingham https://www.mnot.net/
Carsten Bormann
2017-05-10 04:31:07 UTC
Permalink
Post by Mark Nottingham
To close this loop -- the change in -08 isn't sufficiently prominent IME; while the general nature of the change is listed in the Abstract, the actual normative text is very hard to find.
Certainly, let’s see what the IESG decides here.
Post by Mark Nottingham
Given that this is a pretty fundamental change in the operation of a URI scheme, I'd think it at least deserves its own section, if not a separate document.
I don’t agree that this is such a fundamental change here — the /.well-known name space in the URI already was special (by the fact that ws URIs are mapped to http URIs, which do have /.well-known reserved already).

But that doesn’t matter, we should find the best editorial way to document making the well-known URI concept available to WebSocket URIs.

Grüße, Carsten
Patrick McManus
2017-05-12 21:12:52 UTC
Permalink
I have a few thoughts on this draft too.

6455-Websockets was a point in time solution for a problem that was solved
later and better by HTTP/2 (RFC 7540) with the introduction of parallelism,
multiplexing, and non 1:1 bi-directional message capabilities (which 6455
only solves 1/3 of).. 6455 is now considered historical and legacy cruft by
many. I don't know of anyone that would think that if 6455 did not exist it
should be introduced into today's ecosystem. (we would still want a
dev-facing interface doing some of the same things as websockets at a js
layer, but it would not be implemented on the wire 6455 style.)

If the motivation of the websockets-coap binding is to deal with
bi-directional problems better than HTTP/1, the answer to me seems to be to
use HTTP/2 (and maybe an extension of the existing http mapping) rather
than building a parallel system of gateways, proxies, and tunnels on top of
6455. It is unfortunate enough (perhaps unavoidable?) that we have a
parallel stack of constrained protocols without building a gatewaying
system between them rooted in legacy baggage.

The draft as much as acknowledges this with some not totally convincing
handwaving (that is not meant pejoratively - I've been known to hand wave
:))

Although HTTP/2 could also potentially address these requirements,
there would be
additional costs and delays introduced by such a transition.
Currently, there are also fewer HTTP/2 implementations available for
constrained devices in comparison to CoAP.

The aspects of the proposed solution that would seem to pose the largest
challenges for constrained devices, (tcp and tls) are also present in
wss:// as well - which begs the question of whether this is designing a
nominally constrained-device ecosystem actually for
not-so-badly-constrained gateways and they should be using our primary
security, application, and transport standards directly. This parallel
stack has to end somewhere, right?

also, if you stay within the semantics of http, but require 7540 or its
successors for reasons of performance, you will pick up quic for free when
we get there - which is just a specific instance of the general argument
with forking standards.

lastly I think the security considerations (both in that section and
elsewhere) could use some work.

The purpose of websockets-6455 is to deploy a mechanism, consistent with
the web security model, for non-privileged javascript to be able to
communicate using communication patterns that do not fit into the HTTP/1
request/reply pattern well. To be consistent with that security model a
websockets end point needs to opt into doing websockets, potentially doing
a particular sub-protocol, and be expecting this request to have been
triggered by a particular Origin.

The net effect is to prohibit random javascript from the web from spraying
around arbitrary TCP streams behind every user agent's firewall, or
otherwise generating arbitrary botnets (beyond what is allowed by SOP
anyhow).

The coap-tcp-tls-websockets forward-proxy model builds an arbitrary gateway
from websockets to coap based on proxy-uri and would seem to run afoul of
the security model by spraying arbitrary coap around instead of arbitrary
tcp :).. Reverse proxy models, being locked down to particular origins,
work better.

(and as a final nit the websocket handshake examples do not have an Origin
request header as required by 6455 for browsers, and I think browsers are
in scope of this document - but thinking and talking about Origin is a key
part of when websockets is and is not appropriate.).

-Patrick
Post by Mark Nottingham
Post by Mark Nottingham
To close this loop -- the change in -08 isn't sufficiently prominent
IME; while the general nature of the change is listed in the Abstract, the
actual normative text is very hard to find.
Certainly, let’s see what the IESG decides here.
Post by Mark Nottingham
Given that this is a pretty fundamental change in the operation of a URI
scheme, I'd think it at least deserves its own section, if not a separate
document.
I don’t agree that this is such a fundamental change here — the
/.well-known name space in the URI already was special (by the fact that ws
URIs are mapped to http URIs, which do have /.well-known reserved already).
But that doesn’t matter, we should find the best editorial way to document
making the well-known URI concept available to WebSocket URIs.
GrÌße, Carsten
Carsten Bormann
2017-04-19 19:22:05 UTC
Permalink
Post by Mark Nottingham
Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://"
URI, using a well-known URI in the "wss" scheme. However, "wss" is not
defined to use well-known URIs, so this is an invalid use.
Clearly, this is a bug in draft-ietf-core-coap-tcp-tls-07.

I have argued that underlying this is an omission in RFC 6455:

ws:/wss: URIs are translated into http:/https: URIs, and the well-known space is already reserved in the latter, so it would be nonsensical to try to use RFC 5785 /.well-known for something else in the ws:/wss: URI schemes.

Maybe there wasn’t a use case for well-known URIs in WebSockets before, but there is one now, and we would like to remedy this omission in the procedurally simplest possibly way.

So I am proposing to add RFC 5785’s well-known URI mechanism to these URI schemes in the document that needs it, draft-ietf-core-coap-tcp-tls, which by that updates RFC 6455.

Are there any objections to this procedure?

Grüße, Carsten
Carsten Bormann
2017-04-19 19:32:37 UTC
Permalink
Post by Carsten Bormann
So I am proposing to add RFC 5785’s well-known URI mechanism to these URI schemes in the document that needs it, draft-ietf-core-coap-tcp-tls, which by that updates RFC 6455.
Forgot to add the pointer to the simple fix text:

https://github.com/core-wg/coap-tcp-tls/pull/128/files

Grüße, Carsten
Loading...