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

From: "core issue tracker" <[email-masked]>
Date: Tue, 24 Aug 2010 15:07:30 -0000

#23: Virtual server capability?
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  zach@…            
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:  coap-02           
Component:  coap                |     Version:                    
 Severity:  -                   |    Keywords:                    
--------------------------------+-------------------------------------------
 Carsten pointed out that we need to decide whether to support the Uri-
 Authority option in non-proxy requests (and thus the virtual server
 concept). From the original mail:

 I think we need to be clear whether a request to a server should include
 the authority or not.
 Not all servers (if very constrained) may be able to find out whether an
 authority given is actually themselves or not.  Instead of getting simple
 hosts into the habit of accepting any authority, I think it would be
 better to leave the onus to connect to the right place to the client.

 (The underlying question is how important the virtual server concept is.
 If we expect virtual servers to be an important feature, we'll need to
 have the authority in there always, just as HTTP always has a Host:
 header.  If we ask clients to leave out the authority, we can't have
 virtual servers.  We can't have the client make a decision whether the
 server will be using virtual servers.  The above paragraph assumes not
 sending the authority is more important than having the virtual server
 capability.)

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

---

From: Peter Bigot <[email-masked]>
Date: Tue, 24 Aug 2010 12:09:21 -0500

Having a UriAuthority in a request can be a problem if the receiving
server has limited functionality and can't, for example, do a DNS
lookup to verify a host name refers to it.  I think this can be worked
around by simply comparing the authority against a fixed set of
authorities known by the server to be acceptable.  Providing that list
is a configuration issue outside the scope of the protocol; at a
minimum it can be expected that the server can always recognize its
own IP address as a legal authority.

Eliminating the UriAuthority from the REST request sent to a server
would repeat the same mistake made in HTTP/1.0.  That mistake had to
be fixed in HTTP/1.1 to allow HTTP to participate in full REST
transactions where arbitrary intermediate nodes unknown to the client
could provide value-added services without affecting how the client
accessed the resource.

I'd intended to use CoAP as an end-to-end protocol for a common case
of a full-function client collecting data from multiple
reduced-function servers, possibly in different administrative domains
with different intermediaries.  I disagree with the statement in the
discussion of #20 that the UriAuthority is unnecessary to support
transparent proxying.  The backbone of the success of REST on the web
is the ability to use virtual servers and DNS tricks to maintain a
persistent URI for a resource while evolving the infrastructure that
provides that resource.  The uniform interface between components
which is the central feature of REST requires that the complete URI be
present at each step.

If CoAP can't be used end-to-end, then full-function clients like an
energy services platform will have to use HTTP to access the devices,
to enable use of these unknown intermediate services, such as gateways
to clouds of wireless devices.  CoAP becomes useful only as the last
hop between a full-function gateway and the reduced-function devices.
Adequate for simple situations, but seriously limited in its potential
when compared to REST.

Peter

On Tue, Aug 24, 2010 at 10:07 AM, core issue tracker
<[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Zach Shelby <[email-masked]>
Date: Wed, 25 Aug 2010 14:59:47 +0300

> #23: Virtual server capability?

When I earlier said I prefer not to support virtual servers, I should have been more specific. My concern was:

1. On requiring virtual server capability for all end-points. I don't see constrained servers being able to verify host names using DNS. As Peter also pointed out, this can be achieved by attempting to match a pre-configured list of host names. There is a significant chance of misconfiguration here though. Hard to ensure that the host name will actually match (required pre-configuration on both sides), and what are the possible security risks? 

2. Requiring Uri-Authority to be included even when it is repeated overhead. Most requests made by constrained clients will only know the IP address of the host. If we require the Uri-Authority even when it is the same as the destination IP address it is a lot of wasteful overhead. 

I don't find the virtual server concept very useful on constrained servers themselves, nor for constrained clients making direct requests from them. However, I do understand that intermediate or backend infrastructure might make use of preserving the full URI of a request. How can we allow that, without requiring a Uri-Authority in each and every request? 

One solution would be to elide the Uri-Authority when it is the same as the IP destination address. In requests where the Uri-Authority is a host name  then the Uri-Authority option would be included by the client. When a request URI is re-written by an intermediate, then the Uri-Authority could be added if it doesn't already exist.

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: Zach Shelby <[email-masked]>
Date: Wed, 25 Aug 2010 15:17:24 +0300

Peter,

Great that you have a concrete scenario in mind. I also agree that CoAP must be useful end-to-end for many M2M applications (e.g. AMI), a valid design requirement. Could you elaborate with some example request exchanges using intermediates? I would like to understand in your case where and how Uri-Authority is being used. Also it seems to me that the virtual server in the constrained server is not really needed, but preserving the URI in the intermediate infrastructure is enough?

Thanks,
Zach

---

From: Peter Bigot <[email-masked]>
Date: Wed, 25 Aug 2010 16:04:38 -0500

Can we clarify what's meant by "requiring virtual server capability for all
end-points"?  "Virtual server" in the sense of assigning multiple hostnames
to the same IP address and allowing the receiver to sort them out is one
technique that's enabled by providing the authority part of the URI within
the REST message.  But it's not the only time the authority part is needed.

I think most of us agree that anything that requires a constrained server to
do DNS lookups is unacceptable.  I hope we all agree that validation of
authority could be done in much more simple ways, which can be left out of
scope for CoAP.   A quick search failed to find anything in RFC2616 that
specified how the server must interpret the naming authority that's passed
in the Host field, which is really what the UriAuthority option is.  RFC2616
simply specifies that it must be made available, because its absence
prevented useful things from being done.  Consequent to this discovery, I
don't think we even need to specify that an origin server is required to
even look at the authority option.  It could just assume that the resource
is the one it's responsible for.

What I understand you and Carsten to be concerned with is that including the
authority can take a lot of message space, and therefore if it can be
reconstructed from external information there's no need to include it in the
REST message.  So the real question is "how can CoAP support omission of
UriAuthority in requests without impacting its application to REST
architectures that use constrained devices?"

Do we all agree that, regardless of how or whether a constrained server
validates the authority part of the URI, the protocol must ensure it is
available (explicitly or implicitly) in any case where its value is required
for the server to correctly identify the resource?  It's already understood
that this is true when the server is a configured proxy, or when virtual
servers hosted on a transparent proxy are used.  But it can also occur when
the server is an origin server.  See below for some examples.

If so, I can go on to claim that the precondition of "if it can be
reconstructed from external information" is a server property that cannot be
determined a-priori by a client.  Consequently, there is no way for the
client to guarantee availability of the authority part of the resource URI
at the server unless the client always sends it along with the rest of the
URI within the REST message.

Here's the argument:

I assume it's reasonable to expect that CoAP could be implemented using a
standard network API like POSIX sockets.  Recall that a POSIX socket bound
to the wildcard address will generally receive packets addressed to the host
through any IP address bound to any NIC on the host.  The POSIX API does not
provide access to the destination address in the original IP packet.

   - Even if an origin server has only one NIC with one unicast IP address,
   it might have to handle requests for several resources for which the URIs
   have the same path and are distinguished only by distinct multicast or
   anycast addresses, all received over the same socket.
   - An origin server can legitimately be multi-homed: In our systems, we
   have a very constrained node that will need to run CoAP but still has two
   NICs: a serial connection running IPv6/PPP and an 802.15.4 radio.  If I ask
   for a resource with pathname /nic/stats and the authority was the IP address
   of either the PPP link or the radio link, I need to know which so I send the
   right NIC statistics back.
   - Though virtual servers are normally implemented by multiple hostnames
   to the same IP address, nothing prevents me from assigning multiple IP
   addresses to the outward facing NIC of a gateway device and accomplishing
   the same thing.

All these cases hold even if the authority is an IP-literal address.

Also consider the issue of asynchronous responses: unless the token proposal
eliminates the use of the URI to correlate the response with a request, the
server must be able to reconstruct enough of the original URI so that the
*client* can identify the resource.  Some of the cases suggested above are
ones where an absent authority would be difficult to reconstruct for the
response message; and leaving it out could put the client to a lot of effort
to identify which resource was meant.  So much easier if it's just provided
in the original request and can be copied into the response unchanged.

In summary, there are too many cases where dropping the URI authority from
the REST message creates problems for perfectly reasonable applications of
CoAP.  I think the fundamental protocol has to ensure that it's always
possible for the authority to be provided in the REST request.

Now, we could specify a rule that would enable a client to omit the
UriAuthority in a request, like:

   - if the UriAuthority option is absent and the remainder of the URI
   uniquely identifies a resource the server MAY proceed to execute the
   request.   If the server requires the authority to identify the resource it
   MUST reject the request with "400 Bad Request".

With this, you could even try omitting the authority when it's a hostname,
which is when it'll really save space.  However, the client would still
would have to accept that a "400 Bad Request" may indicate it needs to
retransmit the request with the missing information before being sure the
request was really invalid.  I also think it would cause hard-to-diagnose
problems with, for example, DNS misconfigurations.  But if shorter messages
are that important, a system designer might choose to take the risk: it
becomes a quality-of-implementation issue, not a protocol-capability issue.
Unless there're problems I don't see, that'd work for me.  Would it be
acceptable to you?

(Regarding those unseen problems: there's still the open question of what's
to be done if the server has to reconstruct the authority for an
asynchronous response.  It's probably necessary to understand what a
distributed resource addressed by a group name means in REST before we could
figure out what to do then.  For now, a reasonable technique would be to
"400 Bad Request" anything that doesn't have a UriAuthority but requires an
asynchronous response.)

Peter

> 1. On requiring virtual server capability for all end-points. I don't see
constrained servers being able to verify host names using DNS. As Peter also
pointed out, this can be achieved by attempting to match a pre-configured
list of host names. There is a significant chance of misconfiguration here
though. Hard to ensure that the host name will actually match (required
pre-configuration on both sides), and what are the possible security risks?
>
> 2. Requiring Uri-Authority to be included even when it is repeated
overhead. Most requests made by constrained clients will only know the IP
address of the host. If we require the Uri-Authority even when it is the
same as the destination IP address it is a lot of wasteful overhead.
>
> I don't find the virtual server concept very useful on constrained servers
themselves, nor for constrained clients making direct requests from them.
However, I do understand that intermediate or backend infrastructure might
make use of preserving the full URI of a request. How can we allow that,
without requiring a Uri-Authority in each and every request?
>
> One solution would be to elide the Uri-Authority when it is the same as
the IP destination address. In requests where the Uri-Authority is a host
name  then the Uri-Authority option would be included by the client. When a
request URI is re-written by an intermediate, then the Uri-Authority could
be added if it doesn't already exist.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Aug 2010 00:04:01 +0200

On Aug 25, 2010, at 23:04, Peter Bigot wrote:

> Recall that a POSIX socket bound to the wildcard address will generally receive packets addressed to the host through any IP address bound to any NIC on the host.  The POSIX API does not provide access to the destination address in the original IP packet.

Peter,

interesting analyis!

Let me just answer on this one point for now, because it comes up repeatedly:

If you really need to program to POSIX interfaces, then don't do that.
Bind one socket per address.
With Java or .NET, you may be stuck with this (I don't know).

For the rest of us on general-purpose OSes, there is IP_RECVDSTADDR/IP_PKTINFO/IPV6_RECVPKTINFO/...
With luck, as defined in RFC 3542.  Not pretty, but workable.

This is less of an issue for a constrained OS, but, as you say, that is where we probably don't care.

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Thu, 26 Aug 2010 06:18:32 -0500

First, my constrained devices use a POSIX API, because I want to lower the
barrier to entry for people who need to develop on them by supporting a
familiar and standard interface.  One socket per address is not an
acceptable solution.

Second, do not assume that the vast majority of CoAP implementation work
will be done on constrained devices.  There will be many devices, and there
will be a strong need to enhance them with highly capable intermediate
services that allow simple clients (some of them constrained) to communicate
with sleeping nodes and across multiple link layers, provide value-added
composition and abstraction services, translate between vendor resource
representations and URI syntax, etc.  It is support for these unknown
intermediaries that makes REST such a powerful style, and unless CoAP is to
be relegated to a last-hop role these services must be implementable for
CoAP rather than prior to some as-yet-undefined HTTP/CoAP translation.

In terms of complexity of application and time spent in development, CoAP
may well be used more in these environments, for which Python, Java, dot
NET, and other high-level languages and APIs would normally be very
suitable.  Protocol decisions that require use of special tricks and
low-level vendor-specific APIs will ensure a short and unhappy life for CoAP
before it's replaced by something more usable.

Peter

On Wed, Aug 25, 2010 at 5:04 PM, Carsten Bormann <[email-masked]> wrote:

> > Recall that a POSIX socket bound to the wildcard address will generally
> receive packets addressed to the host through any IP address bound to any
> NIC on the host.  The POSIX API does not provide access to the destination
> address in the original IP packet.
>
> Peter,
>
> interesting analyis!
>
> For the rest of us on general-purpose OSes, there is
> IP_RECVDSTADDR/IP_PKTINFO/IPV6_RECVPKTINFO/...

---

From: Zach Shelby <[email-masked]>
Date: Thu, 26 Aug 2010 17:07:49 +0300

On Aug 26, 2010, at 12:04 AM, Peter Bigot wrote:

> In summary, there are too many cases where dropping the URI authority from the REST message creates problems for perfectly reasonable applications of CoAP.  I think the fundamental protocol has to ensure that it's always possible for the authority to be provided in the REST request.
> 
> Now, we could specify a rule that would enable a client to omit the UriAuthority in a request, like:
> 	• if the UriAuthority option is absent and the remainder of the URI uniquely identifies a resource the server MAY proceed to execute the request.   If the server requires the authority to identify the resource it MUST reject the request with "400 Bad Request".

Works for me. Anyone have problems with text like this? If not I will use this as the solution for Ticket #23.

Clearly we need some more text on how to interpret the RequestURI in coap-02, and of course to consider the other implications of URIs with CoAP (e.g. multicast, asynchronous responses etc.). 

Zach

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Aug 2010 16:13:09 +0200

On Aug 26, 2010, at 13:18, Peter Bigot wrote:

> First, my constrained devices use a POSIX API, because I want to lower the barrier to entry for people who need to develop on them by supporting a familiar and standard interface.  One socket per address is not an acceptable solution.

Well, that is not borne out by the facts.

The Internet has a small number UDP-based protocols in heavy use, such as DNS, NTP, DHCP.
I haven't done extensive statistics, but one socket per address indeed appears to be the prevailing implementation strategy.
(The main reason is not that RFC 3542 is not widely available, but that multiple sockets are needed to actually bind each of them to a specific address instead of blindly receiving everything on every interface.)

> Second, do not assume that the vast majority of CoAP implementation work will be done on constrained devices.  

I don't know how to count work, but I completely agree that the availability of CoAP middleware will be a make-or-break influence in the protocol deployment.

So let's, for a moment, work from the assumption that the dominant DNS, NTP and DHCP implementations have it wrong, and we need to make destination address detection work on catch-all sockets.

A quick non-scientific survey indicates potential issues with IP_PKTINFO.../RFC 3542 support in:

vxworks (no idea)
Windows 2000/NT4/9x (fixed in XP, i.e. WinSock 2)
Cygwin (could fix it in 1.7, but didn't yet)
Solaris (?)
Python (fixed with eunuchs library)
Java (need to do JNI calls, unaware of a packaged library for that)

I was unable to make my way through the .NET documentation thicket, but I think WSARecvMsg should be available in .NET; it just isn't clear whether that works right.

Java (and possibly .NET) may indeed be the dealkiller here.  How quaint.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Aug 2010 16:41:47 +0200

> Works for me. Anyone have problems with text like this? If not I will use this as the solution for Ticket #23.

The only real problem I'm seeing right now is that we are starting to build a Kernighan's car here*).

We *need* to come up with more ways to identify errors than mapping everything to 400.
Otherwise debugging will be a nightmare, and debuggability is an important element of deployability.
Maybe having a convention about the payload of such error responses would be good enough.

But it becomes much worse if we expect client implementations to act automatically on this error -- then we need something like the 401 response in HTTP that is a very specific request to send credentials.

Once we start to invent status codes HTTP does not have, we need to decide where to put them in the number space.  Officially, of course, we are free to do as we please, but we want to stay culturally compatible.
We could start at 439 and go down, for instance**).

(So, the rule for what my client code should do, is: don't send Uri-Authority, unless a cached previous 4xx from this address indicates this server wants one?  Might work.  Not beautiful, but neither is 401.)

Note that all this may not suffice to obviate the need for Uri-Authority-Binary.

> Clearly we need some more text on how to interpret the RequestURI in coap-02, and of course to consider the other implications of URIs with CoAP (e.g. multicast, asynchronous responses etc.). 

Yes, please.

Gruesse, Carsten

*) Brian Kernighan's car: its only instrument is a big question mark on the
dashboard, which lights when something goes wrong. "The experienced
driver," Dr Kernighan is quoted as saying, "will know what's wrong."

(Common UNIX koan inspired by the fact that early versions of the ed editor had just one error message, the question mark, which was justified in just that way.)

**)   (Because of our single-byte number encoding, only the digits 0 to 3 are valid in the second position. HTTP goes up to 417, currently; various standard extensions use 42x; Microsoft appears to use 449/450 for parental control and such.  Hmm, 4xx is crowded.  Maybe we should start 6xx, or give up the nice quadrodecimal number system.)