Subject: [core] FW: New Version Notification for draft-thaler-core-redirect-00.txt

From: Dave Thaler <[email-masked]>
Date: Mon, 12 Sep 2016 22:53:29 +0000

COAP Redirects have been requested by the Open Connectivity Foundation (OCF), in which
a couple of IETF'ers (myself, Michael, Darshak, etc.) participate.  As one of the IETF folks in the
discussion, I took the action item to write the I-D to submit to the CoRE WG, since it's not
really OCF-specific.   Michael and Darshak are welcome to back me up here :)

See the I-D for the use case, alternatives considered, and proposed solution.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 12, 2016 3:49 PM
To: Dave Thaler <[email-masked]>
Subject: New Version Notification for draft-thaler-core-redirect-00.txt

A new version of I-D, draft-thaler-core-redirect-00.txt has been successfully submitted by Dave Thaler and posted to the IETF repository.

Name:		draft-thaler-core-redirect
Revision:	00
Title:		COAP Redirects
Document date:	2016-09-12
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/internet-drafts/draft-thaler-core-redirect-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thaler-core-redirect/
Htmlized:       https://tools.ietf.org/html/draft-thaler-core-redirect-00

Abstract:
   This document allows a Constrained Application Protocol (CoAP) server
   to redirect a client to a new URI.  The primary use case is to allow
   a client using multicast CoAP discovery to learn a COAPS endpoint of
   the server, without the server revealing privacy-sensitive
   information.  This improves security and privacy in environments with
   untrusted clients.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Sep 2016 07:55:30 +0200

Dave Thaler wrote:
> The primary use case is to allow
>    information. 

Hi Dave,

so far we have attempted to avoid adding redirect to the CoAP state
machinery.

The specific use case mentioned here already appears to be covered by
the server providing a link-format document with a pointer to one or
more coaps:// accessible link-formats.

But maybe I don't fully understand the use case.

Grüße, Carsten

---

From: Dave Thaler <[email-masked]>
Date: Tue, 13 Sep 2016 18:37:32 +0000

Carsten Bormann wrote:
> The specific use case mentioned here already appears to be covered by the
> server providing a link-format document with a pointer to one or more
> coaps:// accessible link-formats.
> 

There's already an existing resource that the OCF clients use for multicast discovery that
has privacy-sensitive information.   The existing resource can't be changed without
breaking backwards compatibility, but it is ok to break backwards compatibility if the
server is configured to be in a privacy-sensitive mode.

By "providing a link-format document", I assume you mean a new resource (let me know
if I misunderstand).   So I believe you're suggesting creating a new resource for non-legacy
clients to use that will return roughly what a redirect would have returned, and have
the existing resource not respond?  Or return an error?

There's a couple cases on the server side:
1) Server is configured for non-privacy-sensitive config: existing resource can respond to multicast
2) Server is configured for privacy-sensitive config: existing resource must fail.

And on the client side:
1) A legacy client will send multicast query for existing resource: it will work normally with servers
    in the non-privacy-sensitive config.   It will fail with servers in the privacy-sensitive config,
    though how it fails varies based on what solution is chosen.

2) A new client will send multicast query for new resource: new server will respond with success,
     passing back the sort of data it would have put in a redirect, had redirects been used.
     But legacy servers won't respond at all, and the client won't get the answer from this query,
     but has to send out a legacy query to the existing resource in addition.

     The new client doesn't know whether servers are in a privacy-sensitive config or not, so it has to send
     out a query (or queries) that will get responses from both types.   Thus with a new resource,
     your proposal doubles the number of multicast queries on the network.   If the legacy query
     results in an error (rather than no response) from privacy-sensitive servers, this also doubles
     the response implosion problem at the client.

So redirects are at least twice as efficient as not having them, and this efficiency is important
for constrained nodes/networks.

Dave

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Sep 2016 22:26:48 +0200

Hi Dave,

I'm afraid I'm not as familiar with the OCF specs here, so having a
fully fleshed out example would help me understand the problem better
than speaking abstractly about "the resource", "multicast query", etc.

I understood the problem statement as talking about the discovery
process, not about the actual sensor/actuator resources.

So a highly privacy sensitive device might just answer a multicast GET
to /.well-known/core with

<coaps://...>;ct=40

which means "I won't tell you anything about me except over some form of
a secure channel (and I'm not telling what form of that)"; maybe some
additional link relations can fill in the latter point a bit.

If it is a bit more lenient, it might even answer a GET to
/.well-known/core?rt=bar with a similar response, revealing that it does
implement a bar.

I'm not sure I understand how an HTTP-style redirect would help here
except by making things more complicated, so a more detailed example
would help.

HTTP-style redirect is most useful where clients have long-term memories
of links and servers need to update their resource structure during
those long terms.  In the CoRE world, we expect clients to be more agile
on the discovery front, removing the need for redirects.  For the
remaining situations where redirects were popular in HTTP, returning RFC
7807-style error objects may be way more useful, because we then have
the whole media type system to distinguish all the fine points that are
so confusing about redirects.

Grüße, Carsten

---

From: Dave Thaler <[email-masked]>
Date: Thu, 15 Sep 2016 01:43:28 +0000

Short version:

Existing clients do (multicast) GET /oic/res, and the response contains privacy-sensitive information, plus some links
And existing servers will respond to multicast GET /oic/res (but not /.well-known/core).

Redirects allow the following optimized behavior...
New clients do (multicast) GET /oic/res (or /oic/res?rt=bar), and the responses would be:
a) legacy servers, and any new servers that are not configured to be privacy-sensitive, respond with actual content,
      thus keeping latency and messages to a minimum
b) new privacy-sensitive server would instead respond with a redirect to a coaps://<ipaddr>:<port>/oic/res
      A subsequent coaps GET /oic/res to that endpoint returns actual data (just as unicast coaps always did before).

Thus, the overhead is kept to a minimum.

Is that clear?

Dave

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Tuesday, September 13, 2016 1:27 PM
> Cc: [email-masked]
> Subject: Re: [core] FW: New Version Notification for draft-thaler-core-
> redirect-00.txt
> 
> Hi Dave,
> 
> I'm afraid I'm not as familiar with the OCF specs here, so having a fully fleshed
> out example would help me understand the problem better than speaking
> abstractly about "the resource", "multicast query", etc.
> 
> I understood the problem statement as talking about the discovery process,
> not about the actual sensor/actuator resources.
> 
> So a highly privacy sensitive device might just answer a multicast GET to
> /.well-known/core with
> 
> <coaps://...>;ct=40
> 
> which means "I won't tell you anything about me except over some form of a
> secure channel (and I'm not telling what form of that)"; maybe some
> If it is a bit more lenient, it might even answer a GET to /.well-
> known/core?rt=bar with a similar response, revealing that it does implement
> a bar.
> 
> I'm not sure I understand how an HTTP-style redirect would help here except
> by making things more complicated, so a more detailed example would help.
> 
> HTTP-style redirect is most useful where clients have long-term memories of
> links and servers need to update their resource structure during those long
> terms.  In the CoRE world, we expect clients to be more agile on the
> discovery front, removing the need for redirects.  For the remaining
> situations where redirects were popular in HTTP, returning RFC 7807-style
> error objects may be way more useful, because we then have the whole
> media type system to distinguish all the fine points that are so confusing
> about redirects.
> 
> Grüße, Carsten