[core] Cool URIs for the Web of Things (was: Re: Next steps in RD-DNS-SD)

[Christian M. Amsüss]

Hello Carsten, Peter, and CoRE in general,

-IP address

An IP address may change, but the RD deals with URIs, and cool URIs
don't change[TimBL98].

There is no requirement in RD that only cool URIs can be registered.
More seriously, this is one of the cases where wisdom from the Browser
Web enters the discussion here that may not be applicable. We already
ran into that issue with coap+tcp://, and it seems we will run into it
again and again.

Leaving aside details of whether it's IP addresses or also host names
that have become volatile, I think that this piece of browser wisdom is
very applicable here.

Link targets, form targets, or dynamic links are all expressed as URIs.
We'll need to pack all that is required for any client to dereference it
into the URI. Otherwise, all those link targets would need sideband
information a la "The binding is to coap://[2001:db8::1]/foo, but
actually I mean whichever device is currently registered at the
example.com RD with the endpoint name node1", negating the purpose of
single-string identifiers.

The topic is as important now for the Web of Things as it was in 1999
for the browser web, maybe even more so, for back then, a user could act
even on a bad ("Sorry, the page is gone, we've moved the content")
redirect.

Well, we have never defined Uri-Host to carry a DNS name, but here it
indeed seems logical to use that.

If we find a spot in the literal space allowed by URIs but not by DNS
(and AFAICT the only such areas are IPvFuture and fake TLDs like .onion
or .arpa), then lets pick it in this URI scheme -- or do it the next
scheme.

As I see it, we're mixing two different kinds of discovery we're trying
to have the RD do:

1. Finding resources out of a pool

This may involve user interaction and is similar to the DNS-SD process
of listing the instances of a particular service in a domain.

The queries used for this look like
/rd-lookup/res?if=core.s&unit=degC and are expected to return more
than one result.

2. Getting the ephemeral address of a previous result.

Right now, if an endpoint registers without a stable host name (which
it, as you pointed out, might not even have), the lookup 1 returns an
ephemeral "uncool" URI. It will be suitable for immediate consumption,
but adding it to a batch, to a dynlink or just storing it for further
use (browsers would call this bookmarking) is bound to fail sooner or
later.


If RD is to play a role in the latter, I'm all in for that -- but there
should still be a stable URI result somewhere inbetween.

Should a plain RD assist with that? Can it, at all? Should it do so
unconditionally or only when the endpoint asks for cooler URIs?

(RD-DNS-SD might provide some answers by serving a (any) stable name
derived from the d=/ep= parameters pointing to the ephemeral address;
that's not really the DNS-SD part that helps here but just plain DNS, if
that is a suitable tool for this at all.)


To compare this to the DNS-SD processes: There, PTR lookups give the
client an instance name in something like 1, which it can then store
internally. It can not usualy use that information in a link, though.
(I've seen printer-internal URI schemes backslash-escape instance names
for use inside the authority component, but nothing official).
Step 2 is then following SRV, possibly TXT and A/AAAA records.

Instead, IoT devices use the RD to rendezvous. They don’t have
anything but their IP addresses yet, so renumbering events *will*
change those. But that is not a problem, as RD data can be updated
easily.

How does this solve the problem of DNS names being unstable or
brand-dependant, when we expect devices to interoperate on an Internet
scale (ie. without necessarily sharing an RD)?
It just shifts it from the individual device to which
RD is used (and thus trusted with identifying endpoints).

Say we extend the CoAP URI schemes so that
coap://example.com(d=my-domain,ep=node1)/sensor/temp would be resolved
as "Find an RD at example.com, query for an endpoint with those d and ep
parameters, and use its address". This still needs DNS as initial
rendevouz point and just adds a step.

Granted, we could just expect every network to provide an RD that hooks
into a global RD network, but that'd go further than even the wild
speculation in core-rd-replication.

We could also expect devices that communicate to share an RD, but while
that migh work in an enterprise environment, it brings the danger of
vendor silo-ification to consumers.

Actually, the main reason to pursue the RD-to-DNS-SD mapping is to
have an ordered way to export RD information over to the DNS, [...]

I think that RD-DNS-SD can already do that no matter how we decide in
the open questions.

The topic we're talking about here is much more a general RD, possibly
also CoRE or T2TRG issue.

(Changing the recipients list to reflect that).

If a device expects to have a longer life cycle than its assigned
address, IMO it should not register with an IP literal. (This is a
general RD topic, actually).

No, it should keep simply keep its RD info updated.

How about "it should keep the RD updated, and ask the RD to hand out
something more persistent instead"? (Or can the RD infer that request
from the regiatration?)


Best regards
Christian

[Carsten Bormann]

Hi Christian,

this is a long discussion. We had some of this in Ludwigsburg, but we
didn't continue it very much since, and maybe it is time to do so.

This discussion cannot he had without thinking about *identity*.
(In the sense of RFC4949, and not in the English sense.)

In the IoT, many people are thinking about *Device Identity* (DI).
Device Identity stays with a specific device and is generally
immutable. It may spawn derived identities such as AIKs, but this is
not of major interest for the present discussion.

However, DI is not what is needed in most practical applications. In
reality, devices break, get lost, or have to eb taken out of service
for other reasons. While some devices allow the transfer of their
device identity to a new device (a procedure known by some as
fal-tor-pan), there are some difficulties with that [security; the new
device may not be completely identical to the old one], so I'll ignore
the possibility for now.

So what do we do when we have to replace the temp sensor in room 451?
We install a new device, with a new DI, but assign it the same "Role
Identity" (RI). So everyone can work with "the temp sensor in room
451", before or after the change, under the continuing RI.

But how do we communicate with a device or a holder of a role? We
also need an identity for communication, which I'll call the "Plumbing
Identity" (PI).

In the Browser Web, PI and RI are conflated. This has worked
reasonably well, so well that sometimes people think this is a
founding principle of the Web. Really, it was a historical accident
-- we initially used a PI as an RI, simply assuming that the plumbing
was stable and secure enough, with DNS as the indirection allowing for
more stable PIs. When it became apparent that neither DNS nor the
plumbing itself were secure enough, the RI aspect of the PI was
reinforced by authenticating it via TLS and the PKI.

What we really will need to make the IoT work are Semantic Identities
(SI). Room 451 may have a refrigerator, and that may also have a
temperature sensor for the ambient temperature. That does not make
the refrigerator *the* new "temp sensor in Room 451", it still keeps
its role as refrigerator. It may also have some semantic properties
(latency of the sensor, accuracy etc.) that make it differ from "the
temp sensor in Room 451" and are part of its SI. If I need the
temperature in Room 451, I may want to make do with the fridge's
sensor if the other sensor is down, or I may want to fuse the sensors.
If you go to an RD and look for a resource that is intrinsically a
temp sensor for ambient temperatures and contextually in Room 451, you
are essentially implementing SI. But that is a digression for the
current discussion.

Back to DIs, PIs, and RIs.

PIs come in different forms. If your stable PI is a DNS name, you
need to convert this into an IP address (possibly via a service
record) before it becomes useful as a PI. You don't want to do this
for each interaction, so you keep the directly usable PI (IP address)
around, and the question becomes interesting how often you run the
protocol to convert a stable PI into a usable one. There is little
difference between RD and DNS here, except that RD has space for
useful semantic attributes and can talk about resources, not just
endpoints. SRV records could be used for transport selection in DNS;
in RD that would be built in.

So what do we write into those cool URIs? In the Browser Web, DNS
names (and only occasionally IP addresses); transport negotiation
happens in TLS (ALPN). For CoRE: if we want to use RD as the
indirection mechanism toward directly usable PIs, the resource
descriptions to be found there will need to provide IP addresses in
them (just as they usually have a transport binding in them, which a
cool URI would not). The URI is a natural place for an IP address,
but it is not the only way. In any case, for a cool URI we would
still need to find what could be the stable identifier to be put into
the authority -- OCF has an idea for that...

Grüße, Carsten

[Carsten Bormann]

Post by Carsten Bormann
Ludwigsburg

Forgot to add a reference:

https://github.com/t2trg/2016-10-implementers/blob/master/slides/T2TRG-2016-10-implementers-chair-material.pdf
From slide 35…

Grüße, Carsten

[Christian M. Amsüss]

Hello Carsten,

Post by Carsten Bormann
Back to DIs, PIs, and RIs.

These are convenient terminology

Post by Carsten Bormann
PIs come in different forms. If your stable PI is a DNS name, you
need to convert this into an IP address (possibly via a service
record) before it becomes useful as a PI. You don't want to do this
for each interaction, so you keep the directly usable PI (IP address)
around, and the question becomes interesting how often you run the
protocol to convert a stable PI into a usable one.

Let me try to link this to URI concepts and schemes we have so far, and
link it to the identity's authenticity[1]:

* Transport specific URIs with address literals
(coap+tcp://[2001:db8::1]/ & co):

These clearly encode PIs.

The client can not establish whether the server it talks to uses that
identity authentically (short of trusting the network).

* Transport specific URIs with DNS names:

Those can be RIs or DIs depending on how the name owner uses DNS, with
some plumbing information included (the protocol) and the rest easily
derivable (doing plain DNS lookups).

The lookup result can not be treated as a derived URI, for that loses
"virtual host" information the server might rely on.

For the TLS based schemes, the server proves the authenticity of its
identity during the handshake.

* ocf://{uuid}/ style URIs:

Clearly encoding DIs ([2] actually calls the URI's authority component
Device ID). Those addresses are used in parallel with IP-literal URIs
and resolved in what appears to be a mixture of RD operation and
side-banding the literal URIs in target attributes of links to the
ocf:// URIs.

AFAICT no information is encoded in the URI that allows a client to
establish the server identity's authenticity; certificates can sign a
device UUID, but that obviously only works if both already share a
trust anchor.

There is a concept of UAIDs based on cryptographic hashes (urn:usid:
URIs, which are also used in CN of certificates), but I don't
understand how those are interlinked.

I think that on the way to A Big Solution, some questions we should ask
ourselves are:

* Of all the form of identities, do we need to have URI representations
of all of them? (Esp. Is it an issue that our PIs can not always be
expressed in URIs?)

* Can we use the more abstract identities on embedded devices? (RIs
should be doable, SIs are still a bit fuzzy). Can we provide
resolution mechanisms such that we can always operate on RIs? (Are
there situations where we *want* a DI or PI URI? When talking *about*
a device, DI and RI intermix.)


Best regards
Christian


[1] RFC4949 p148 par.1 talks about the identity's authenticity and
eligibility. I think that in a client-server context, the former
matters and should be derivable from a URI, while the latter does not
because it'd need to be established when the client receives the URI,
not when it dereferences it.

[2] https://openconnectivity.org/specs/OCF_Core_Specification_v1.3.0.pdf