Subject: Re: [core] #23: Virtual server capability?

From: Klaus Hartke <[email-masked]>
Date: Wed, 1 Sep 2010 18:23:28 +0200

I think the problem we're trying to solve is as follows:

We have the commonly occurring pattern of a CoAP server with which
communication is only possible in a meaningful/practical way if the
request is moved through some intermediary node, for example, because
the server is a sleep node or it is located in a subnet that is only
reachable from the intermediary node.

One solution to this problem is what we call a "Virtual server
capability": instead of the IP address of the server, we specify the
IP address of the intermediary node in the A/AAAA DNS record for the
server. All requests are then sent to the intermediary node which
needs a way to distinguish between requests intended for different
servers.

This solution has two implications:

- All request must specify the Uri-Authority Option, because a client
cannot know if a resolved IP address refers to a server or such an
intermediary node.

- All servers should know their DNS name, so they can decide if a
request is intended for them or if they are expected to act as a
proxy.

Since DNS names can be quite verbose, we'd like to be able to omit the
Uri-Authority Option in most cases.

I don't know if this a problem or not, but the sweet-spot for server
implementations is to simply accept any DNS name in the Uri-Authority
Option.

Another solution is to shift the burden from the server to the client:
instead of the IP address of the server, we specify the IP address of
the intermediary node in the (say) SRV DNS record for the server. If
such a record is present, the client knows that the IP address refers
to a CoAP proxy (otherwise, the client falls back to the A/AAAA DNS
record).

- Since the client knows if it's communicating with a proxy or not, it
can include or omit the Uri-Authority Option accordingly. The
Uri-Authority Option can likely be omitted in most cases.

- A server can determine if it's expected to act as proxy or server
simply by checking if the Uri-Authority Option is present or not.

The sweet-spot for client implementations is either to correctly
implement this feature, because otherwise it wouldn't work, or to not
implement it, but not to implement wrong/problematic behaviour.

Many DNS APIs do not provide functions for retrieving non-A/AAAA DNS
records though.

(Note that both solutions allow the intermediary node to act on behalf
of the guarded server, or to expose a set of "virtual" servers that do
not exist as actual, separate nodes.)

I think both solutions can be tweaked to solve the problem. The first
question is, of course: Is the problem the one stated above or is it
actually a different one?

Are there other possible solutions to the problem that we haven't
thought about yet?

It has repeatedly been stated that it is an essential part of REST
that the Uri-Authority Option must always be present. I'm not sure if
I understand this fully yet. Where exactly does it come into play,
i.e. what problem does it solve? How can we recognise a different
solution to the same problem?

The problem scenario should also become very interesting in the light
of end-to-end security. Do we need to think about a mechanism to
securely allow a CoAP node to act on behalf of another one?

Klaus

---

From: Peter Bigot <[email-masked]>
Date: Wed, 1 Sep 2010 18:22:38 -0500

I agree with the problem statement and the implications, though I
would make it clear that the server knowing its DNS name should not be
taken to imply that the server must speak DNS as a protocol.  It just
has to recognize itself when presented with an authority.

My objection to solutions that push the burden to the client is due to
the core REST principle of consistent interfaces.  Under REST, all the
client knows is the URI, and some basic information about the resource
state description.  In REST, there can be an arbitrary number of
intermediate servers between the client and the origin server, all of
which do something that's important to somebody, but which must look,
from the client's REST perspective, exactly like the origin server.

Adding a requirement that the client know whether it is talking to the
real origin server directly makes it difficult for client/server
connections that traverse different administrative domains to adapt to
changes in how the resources are provided (e.g., addition of
intermediate nodes).  Imposing requirements that clients support
additional DNS query facilities or other ways to obtain information
that is not part of the URI but is required to connect to the
identified resource makes implementing clients and managing CoAP
environments both more complex.

The reason I keep saying the authority is an essential part of REST is
because the authority is an essential part of a URI, and REST uses
URIs to identify the resources whose state it transfers.  In support
of this, I again refer to Fielding's dissertation (section 6.3.2.1)
where he admitted that allowing the authority to be dropped in
HTTP/1.0 was one of the worst mistakes they made.  When part of a URI
is removed, the URI no longer uniquely identifies the resource.  *If*
the removed part can be restored on the (intermediate) server(s)
through envelope or external information that is maintained and made
available at every stage of the entire (unknown) underlying transport
network that carries the REST message, then the information is not
really lost and the resource remains uniquely identified.

Clearly, carrying the original URI authority within the REST message
all the way from client to origin sever would retain this information.
 I don't believe we have clearly proven that there is an alternative
approach that will work in all REST-ful architectures and all
reasonable implementation environments, including the ones I outlined.
 The authors of HTTP/1.1 found they could not solve the problem any
other way.

I have no objection to providing wording that allows the Uri-Authority
option to be omitted in a situation where the architect of a
particular CoAP service or installation has ensured it is safe to do
so.  That's why I proposed wording that allows this.  I do, though,
object to creating a specification that mandates situations where the
authority part cannot be retained in a REST message, imposes the use
of "complex" solutions to the problem thus created, and doesn't
provide a fallback that allows the client to recover automatically
when the server disagrees about the importance of having the authority
or can't successfully figure out what it was supposed to be.  Which is
where it looked like we were going.  I'm afraid that doing that would
prevent CoAP from being used in a full-featured REST-ful
architectures.

(I'm also afraid of how to define a CoAP/HTTP bridge in situations
where it's difficult to maintain in CoAP information that HTTP expects
to be provided, so would prefer to limit those situations, at least
until we understand better how to solve that problem.)

I'm satisfied with the current disposition of this ticket.  Clients
that do not want to include Uri-Authority are free to omit it.
Servers that are simplified by requiring its presence are free to
require it.  When these choices conflict, the two can still
communicate: the client simply adds information it already has and
retransmits the request, and the server gets what it needs[*].  All is
good, no?

Peter

[*] Carsten is absolutely right about the ugliness of using "400 Bad
Request" to identify this situation.  In my proposed text I
specifically chose not to confuse the issue by inventing a new result
code.  That's a whole separate issue, peripheral to this one, and on
which I currently hold no opinions.

On Wed, Sep 1, 2010 at 11:23 AM, Klaus Hartke <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Zach Shelby <[email-masked]>
Date: Wed, 8 Sep 2010 13:38:11 +0300

> retransmits the request, and the server gets what it needs[*].  All is

Both Klaus and Peter have captured the problem well, although with slightly different terms. I think the only reason we were dropping Uri-Authority from normal requests in coap-01 is that we didn't have transversing transparent REST intermediates on our radar so far. I also agree with Peter that moving the burden to the client is not a good solution, however in some cases clients may be configured with intermediate proxy information just as they are in HTTP. For the solution to Ticket #23, I would like to add a rule to those suggested by Peter:

1  If the Uri-Authority option is absent and the remainder of the URI uniquely identifies a resource the server MAY proceed to execute the request.  
2. If the server is able to determine the IP destination address of the request, it SHOULD/MAY? assume this as the authority of the URI. 
3. If no authority can be determined and the server requires the authority to identify the resource it MUST reject the request with "400 Bad Request" [*]

Is this acceptable? It makes use of the IP destination address possible for stacks which give access to it.

> which I currently hold no opinions.

Right, I will use 400 Bad Request for now, and we need to separately discuss whether to add a new response code for this... 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Peter Bigot <[email-masked]>
Date: Wed, 8 Sep 2010 10:01:06 -0500

I would accept MAY in the new rule.  I still think this is a bad idea
for consistent end-to-end REST processing, so SHOULD makes me
uncomfortable, especially as it's conditional on an implementation
choice.  MAY is more consistent with rule 1 as well.

Peter

---

From: Zach Shelby <[email-masked]>
Date: Thu, 9 Sep 2010 13:42:03 +0300

Allright, let's give it a try with MAY. If this rule becomes problematic in practice I am happy to remove it later on as well. 

Zach

---

From: "core issue tracker" <[email-masked]>
Date: Thu, 09 Sep 2010 10:45:15 -0000

#23: Virtual server capability?
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  zach@…            
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:  coap-02           
Component:  coap                |     Version:                    
 Severity:  -                   |    Keywords:                    
--------------------------------+-------------------------------------------

Comment(by zach@…):

 From a longish WG list discussion led by Peter Bigot it became clear there
 is a valid use case for the URI Authority in CoRE. However, for efficiency
 it should be possible for a client to leave the URI-Authority out. The
 following rule was defined for coap-02:

 1  If the Uri-Authority option is absent and the remainder of the URI
 uniquely identifies a resource the server MAY proceed to execute the
 request.
 2. If the server is able to determine the IP destination address of the
 request, it MAY assume this as the authority of the URI.
 3. If no authority can be determined and the server requires the authority
 to identify the resource it MUST reject the request with "400 Bad Request"
 [*]

 [*] 400 Bad Request is pretty badly overloaded, so it is still to be
 determined if a new error code is needed for this case.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/23#comment:1>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Thu, 09 Sep 2010 11:38:03 -0000

#23: Virtual server capability?
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |        Owner:  zach@…            
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:  coap-02           
Component:  coap                |      Version:                    
 Severity:  -                   |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by zach@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Rules added to Section 2.5.2 of coap-02 and proxy section fixed.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/23#comment:2>
core <http://tools.ietf.org/core/>