Draft: draft-ietf-core-resource-directory

Commentary: This is an initial rough and overly variable suggestion to address the issues discussed as a follow - up to the DTLS replay window comments . The approaches all have their up- and downsides , and I 'm not sure yet which are worth keeping . The nice thing about ETag is that it should be largely uncontroversial in its semantics , well established , and resource specific . The only downside is that we 'd have to mandate that the client send it every time , for otherwise there 's no way of recovery . ( And recovery is needed : Think of what happens if the client sends a request , the server updates the ETag and returns it with a response that gets lost . Client retransmits , but the request is idempotent and thus not deduplicated , and the client gets a 4.12 . Or can that carry an ETag ? It probably intends to tag a representation . And can the server 4.12 when ETag is missing ? ) Echo is what we talked about in the last interim , and largely straightforward . It 's really about freshness and not about resource state , and thus may need to play nicely with other users of Echo on the same server . Introspecting OSCORE sequence numbers ... do we want to go there ? ( And if yes , can we do anything for DTLS where sequence numbers are usually not exposed through the libraries ? ) It would n't be fully without precedent because the sequence numbers are used to order observe notifications , and were under consideration ( but insufficient for ) atomic block reassembly . However , these were about CoAP options and not applications . How to tell the client to re - encrypt at seqno failure is open ( although Echo : anything - but - the - current - value would practically suffice ) . Further questions arise when there are multiple OSCORE contexts all admissible for interaction with that resource . Unique Registration Resource names are just in there for completeness , they do n't give a full solution . 
 Now has text reflecting the decision to go with Echo . Not something I 'd consider handing out ( ie . I have n't even had a second look after writing ) , but good enough to check into version control . 
 Please review based , ideally based on the github delta at ( The diffs of the rendered texts advertised on the github page are currently unreliable ; wo n't investigate there before the cut - off ) . 
 Thanks , that is helpful as it is . There is only a SHOULD for the checks that leaves the door a gap open for applications where none of the consequences matter . In particular , I envision that heavily SCHC'd LoRA devices would update their registrations with an implied No - Response and thus radio silence from their RD ( and thus freshness assertions for the keepalives can become difficult ) . The " skipping " section is there to ensure that in these cases , users are aware of the consequences . 
 HI  , thanks for all the work , I am not quite familiar with the echo request and freshness concept . Reading your text , I would assume that a full serialized approach would do . That means the RD can only handle sequential accesses one after the other . If you want more interleaving of request , some serializability algorithms should be applied . BUt that is very tme consuming . Sorry , not being able to give mor reeasobnable feedback quickly .  
 The door is open for an RD to do that , by means of the " ... that altered that state in a conflicting way " . I 'm appreciating it already as it is :-) , thanks 
 ... and other terms defined in terminology . Best addressed after and the anchor changes are through . 
 I only have little time before cut - off , but I 've read the diff in question . Without knowing the details , the reasoning in the request freshness section looks right . I did n't understand the basic assumption in the " skipping freshness checks " section : Why can RD based applications be built in which request freshness checks are not performed ( unless freshness is not required , in which case this is n't a problem ) ? Please let me know what more I should do . A syntax error : { { example - freshness }
Paragraph (version A):
Commissioning Tool (CT) is a device that assists during the
installation of the network by assigning values to parameters,
naming endpoints and groups, or adapting the installation to the
needs of the applications.
Paragraph (version B):
Commissioning Tool (CT) is a device that assists during
installation events by assigning values to parameters, naming
endpoints and groups, or adapting the installation to the needs of
the applications.
Paragraph (version B):
Data in the RD can only be provided by the device which hosts those
data or a dedicated Commissioning Tool (CT).  These CTs act on behalf
of endpoints too constrained, or generally unable, to present that
information themselves.  No other client can modify data in the RD.
Changes to the information in the RD do not propagate automatically
back to the web servers from where the information originated.
Paragraph (version A):
The web server is free to choose links it deems appropriate to be
exposed in its ".well-known/core".  Typically, the links describe
resources that are served by the host, but the set can also contain
links to resources on other servers (see examples in RFC6690 page
14).  The set does not necessarily contain links to all resources
served by the host.
Paragraph (version B):
The web server is free to choose links it deems appropriate to be
exposed in its "/.well-known/core".  Typically, the links describe
resources that are served by the host, but the set can also contain
links to resources on other servers (see examples in RFC6690 page
14).  The set does not necessarily contain links to all resources
served by the host.
Paragraph (version A):
Over the last few years, mobile operators around the world have
focused on development of M2M solutions in order to expand the
business to the new type of users: machines.  The machines are
connected directly to a mobile network using an appropriate embedded
wireless interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing
short and wide range wireless interfaces.  From the system design
point of view, the ambition is to design horizontal solutions that
can enable utilization of machines in different applications
depending on their current availability and capabilities as well as
application requirements, thus avoiding silo like solutions.  One of
the crucial enablers of such design is the ability to discover
resources (and thus the endpoints they are hosted on) capable of
providing required information at a given time or acting on
instructions from the end users.
Paragraph (version B):
Over the last few years, mobile operators around the world have
focused on development of M2M solutions in order to expand the
business to the new type of users: machines.  The machines are
connected directly to a mobile network using an appropriate embedded
wireless interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing
short and wide range wireless interfaces.  The ambition in such
systems is to build them from reusable components.  These speed up
development and deployment, and enable shared use of machines across
different applications.  One crucial component of such systems is the
discovery of resources (and thus the endpoints they are hosted on)
capable of providing required information at a given time or acting
on instructions from the end users.
Paragraph (version B):
Home and commercial building automation systems can benefit from the
use of IoT web services.  The discovery requirements of these
applications are demanding.  Home automation usually relies on run-
time discovery to commission the system, whereas in building
automation a combination of professional commissioning and run-time
discovery is used.  Both home and building automation involve peer-
to-peer interactions between endpoints, and involve battery-powered
sleeping devices.  Both can use the common RD infrastructure to
establish device interactions efficiently, but can pick security
policies suitable for their needs.
Paragraph (version B):
Two phases can be discerned for a network servicing the system: (1)
installation and (2) operation.  During the operational phase, the
network is connected to the Internet with a Border Router (e.g. a
6LoWPAN Border Router (6LBR), see RFC6775) and the nodes connected to
the network can use the Internet services that are provided by the
Internet Provider or the network administrator.  During the
installation phase, the network is completely stand-alone, no Border
Router is connected, and the network only supports the IP
communication between the connected nodes.  The installation phase is
usually followed by the operational phase.  As an RD's operations
work without hard dependencies on names or addresses, it can be used
for discovery across both phases.
Paragraph (version B):
A (re-)starting device may want to find one or more RDs before it can
discover their URIs.  Dependent on the operational conditions, one or
more of the techniques below apply.
Paragraph (version B):
When answering a multicast request directed at a link-local group,
the RD may want to respond from a routable address; this makes it
easier for registrants to use one of their own routable addresses for
registration.  When RFC6724 is used for source address selection,
this can be achieved by applying the changes of its Section 10.4,
picking public addresses in its Section 5 Rule 7, and superseding
rule 8 with preferring the source address's precedence.
Paragraph (version B):
With security policies where the client requires the RD to be
authorized to act as an RD, that authorization may be limited to
resources on which the authorized RD advertises the adequate resource
types.  Clients that have obtained links they can not rely on yet can
repeat the URI discovery step at the /.well-known/core resource of
the indicated host to obtain the resource type information from an
authorized source.
Paragraph (version A):
When the (ep, d) value pair of the registration-request is equal
to an existing registration, the content and parameters of the
existing registration are replaced with the content of the
registration request.
Paragraph (version B):
When the (ep, d) value pair of the registration-request is equal
to an existing registration, the content and parameters of the
existing registration are replaced with the content of the
registration request.  Like the later changes to registration
resources, security policies (policies) usually require such
requests to come from the same device.
Paragraph (version B):
Operations on the Registration Resource are sensitive to reordering;
freshness describes how order is restored.
Paragraph (version A):
An update MAY update the lifetime or the base URI registration
parameters "lt", "base" as in registration.  Parameters that are not
being changed SHOULD NOT be included in an update.  Adding parameters
that have not changed increases the size of the message but does not
have any other implications.  Parameters MUST be included as query
parameters in an update operation as in registration.
Paragraph (version B):
An update MAY update registration parameters like lifetime, base URI
or others.  Parameters that are not being changed should not be
included in an update.  Adding parameters that have not changed
increases the size of the message but does not have any other
implications.  Parameters are included as query parameters in an
update operation as in registration.
Paragraph (version A):
Base URI (optional).  This parameter updates the Base URI
established in the original registration to a new value.  If
the parameter is set in an update, it is stored by the RD as
the new Base URI under which to interpret the relative links
present in the payload of the original registration, following
the same restrictions as in the registration.  If the parameter
is not set in the request but was set before, the previous Base
URI value is kept unmodified.  If the parameter is not set in
the request and was not set before either, the source address
and source port of the update request are stored as the Base
URI.
Paragraph (version B):
Base URI (optional).  This parameter updates the Base URI
established in the original registration to a new value, and is
subject to the same restrictions as in the registration.  If
the parameter is set in an update, it is stored by the RD as
the new Base URI under which to interpret the relative links
present in the payload of the original registration.  If the
parameter is not set in the request but was set before, the
previous Base URI value is kept unmodified.  If the parameter
is not set in the request and was not set before either, the
source address and source port of the update request are stored
as the Base URI.
Paragraph (version A):
The following example shows how the registering endpoint updates its
registration resource at an RD using this interface with the example
location value: /rd/4521.
Paragraph (version B):
The following example shows how the registering endpoint resets the
timeout on its registration resource at an RD using this interface
with the example location value: /rd/4521.
Paragraph (version B):
Some security mechanisms usable with an RD allow out of order request
processing, or do not even mandate replay protection at all.  The RD
needs to ensure that operations on the registration resource are
executed in an order that does not distort the client's intentions.
Paragraph (version B):
This ordering of operations is expressed in terms of freshness as
defined in I-D.ietf-core-echo-request-tag.  Requests that alter a
resource's state need to be fresh relative to the latest request that
altered that state in a conflicting way.
Paragraph (version B):
To keep latency and traffic added by the freshness requirements to a
minimum, RDs should avoid naive (sufficient but inefficient)
freshness criteria.
Paragraph (version B):
State counter.  The RD can keep a monotonous counter that
increments whenever a registration changes.  For every
registration resource, it stores the post-increment value of that
resource's last change.  Requests altering them need to have at
least that value encoded in their Echo option, and are otherwise
rejected with a 4.01 Unauthorized and the current counter value as
the Echo value.  If other applications on the same server use Echo
as well, that encoding may include a prefix indicating that it
pertains to the RD's counter.
Paragraph (version B):
The value associated with a resource needs to be kept across the
removal of registrations if the same registration resource is to
be reused.
Paragraph (version B):
The counter can be reset (and the values of removed resources
forgotten) when all previous security associations are reset.
Paragraph (version B):
This is the "Persistent Counter" method of I-D.ietf-core-echo-
request-tag Appendix A.
Paragraph (version B):
Preemptive Echo values.  The current state counter can be sent in
an Echo option not only when requests are rejected with 4.01
Unauthorized, but also with successful responses.  Thus, clients
can be provided with Echo values sufficient for their next request
on a regular basis.
Paragraph (version B):
While endpoints may discard received Echo values at leisure
between requests, they are encouraged to retain these values for
the next request to avoid additional round trips.
Paragraph (version B):
If the RD can ensure that only one security association has
modifying access to any registration at any given time, and that
security association provides order on the requests, that order is
sufficient to show request freshness.
Paragraph (version B):
The other examples do not show Echo options for simplicity, and
because they lack the context for any example values to have meaning.
Paragraph (version A):
Resource lookup results in links that are semantically equivalent to
the links submitted to the RD.  The links and link parameters
returned by the lookup are equal to the submitted ones, except that
the target and anchor references are fully resolved.
Paragraph (version B):
Resource lookup results in links that are semantically equivalent to
the links submitted to the RD by the registrant.  The links and link
parameters returned by the lookup are equal to the originally
submitted ones, except that the target and anchor references are
fully resolved.
Paragraph (version A):
If the base URI of a registration contains a link-local address, the
RD MUST NOT show its links unless the lookup was made from the same
link.  The RD MUST NOT include zone identifiers in the resolved URIs.
Paragraph (version B):
If the base URI of a registration contains a link-local address, the
RD MUST NOT show its links unless the lookup was made from the link
on which the registered endpoint can be reached.  The RD MUST NOT
include zone identifiers in the resolved URIs.
Paragraph (version A):
The page and count parameters are used to obtain lookup results in
specified increments using pagination, where count specifies how many
links to return and page specifies which subset of links organized in
sequential pages, each containing 'count' links, starting with link
zero and page zero.  Thus, specifying count of 10 and page of 0 will
return the first 10 links in the result set (links 0-9).  Count = 10
and page = 1 will return the next 'page' containing links 10-19, and
so on.
Paragraph (version A):
A link matches a search criterion if it has an attribute of the same
name and the same value, allowing for a trailing "*" wildcard
operator as in Section 4.1 of RFC6690.  Attributes that are defined
as "link-type" match if the search value matches any of their values
(see Section 4.1 of RFC6690; e.g. "?if=tag:example.net,2020:sensor"
matches ";if="example.regname tag:example.net,2020:sensor";").  A
resource link also matches a search criterion if its endpoint would
match the criterion, and vice versa, an endpoint link matches a
search criterion if any of its resource links matches it.
Paragraph (version B):
A link matches a search criterion if it has an attribute of the same
name and the same value, allowing for a trailing "*" wildcard
operator as in Section 4.1 of RFC6690.  Attributes that are defined
as "relation-types" (in the link-format ABNF) match if the search
value matches any of their values (see Section 4.1 of RFC6690; e.g.
"?if=tag:example.net,2020:sensor" matches ";if="example.regname
tag:example.net,2020:sensor";").  A resource link also matches a
search criterion if its endpoint would match the criterion, and vice
versa, an endpoint link matches a search criterion if any of its
resource links matches it.
Paragraph (version B):
Additional query parameters "page" and "count" are used to obtain
lookup results in specified increments using pagination, where count
specifies how many links to return and page specifies which subset of
links organized in sequential pages, each containing 'count' links,
starting with link zero and page zero.  Thus, specifying count of 10
and page of 0 will return the first 10 links in the result set (links
0-9).  Count = 10 and page = 1 will return the next 'page' containing
links 10-19, and so on.
Paragraph (version A):
The following example shows a client performing a lookup of all
resources of all endpoints of a given endpoint type.  It assumes that
two endpoints (with endpoint names "sensor1" and "sensor2") have
previously registered with their respective addresses
"coap://sensor1.example.com" and "coap://sensor2.example.com", and
posted the very payload of the 6th request of section 5 of RFC6690.
Paragraph (version A):
The endpoint lookup returns registration resources which can only be
manipulated by the registering endpoint.
Paragraph (version B):
The following example shows a client performing a lookup of all
resources of all endpoints of a given endpoint type.  It assumes that
two endpoints (with endpoint names "sensor1" and "sensor2") have
previously registered with their respective addresses
"coap://sensor1.example.com" and "coap://sensor2.example.com", and
posted the very payload of the 6th response of section 5 of RFC6690.
Paragraph (version B):
The endpoint lookup returns links to and information about
registration resources, which themselves can only be manipulated by
the registering endpoint.
Paragraph (version A):
An RD can report endpoints in lookup that are not hosted at the same
address.  Lookup clients MUST be prepared to see arbitrary URIs as
registration resources in the results and treat them as opaque
identifiers; the precise semantics of such links are left to future
specifications.
Paragraph (version B):
An RD can report registrations in lookup whose URI scheme and
authority differ from the lookup resource's.  Lookup clients MUST be
prepared to see arbitrary URIs as registration resources in the
results and treat them as opaque identifiers; the precise semantics
of such links are left to future specifications.
Paragraph (version A):
When certificates are used as authorization credentials, the
sector(s) and endpoint name(s) can be transported in the subject.  In
an ACE context, those are typically transported in a scope claim.
Paragraph (version B):
It is up to the concrete security policy to describe how endpoint
name and sector are transported when certificates are used.  For
example, it may describe how SubjectAltName dNSName entries are
mapped to endpoint and domain names.
Paragraph (version A):
An RD may also require that only links are registered on whose anchor
(or even target) the RD recognizes as authoritative of.  One way to
do this is to demand that the registrant present the same credentials
as a client that they'd need to present if contacted as a server at
the resources' URI, which may include using the address and port that
are part of the URI.  Such a restriction places severe practical
limitations on the links that can be registered.
Paragraph (version A):
When registrants publish information in the RD that is not available
to any client that would query the registrant's .well-known/core
interface, or when lookups to that interface are subject so stricter
firewalling than lookups to the RD, the RD may need to limit which
lookup clients may access the information.
Paragraph (version B):
An RD may also require that links are only registered if the
registrant is authorized to publish information about the anchor (or
even target) of the link.  One way to do this is to demand that the
registrant present the same credentials as a client that they'd need
to present if contacted as a server at the resources' URI, which may
include using the address and port that are part of the URI.  Such a
restriction places severe practical limitations on the links that can
be registered.
Paragraph (version B):
As above, the impact of undesirable links depends on the extent to
which the lookup client relies on the RD.  To avoid the limitations,
RD applications should consider prescribing that lookup clients only
use the discovered information as hints, and describe which pieces of
information need to be verified because they impact the application's
security.  A straightforward way to verify such information is to
request it again from an authorized server, typically the one that
hosts the target resource.  That similar to what happens in discovery
when the URI discovery step is repeated.
Paragraph (version B):
When registrants publish information in the RD that is not available
to any client that would query the registrant's /.well-known/core
interface, or when lookups to that interface are subject so stricter
firewalling than lookups to the RD, the RD may need to limit which
lookup clients may access the information.
Paragraph (version B):
For this policy to be usable without configuration, clients should
not set a sector name in their registrations.  An RD can set a
default sector name for registrations accepted under this policy,
which is useful especially in a segmented setup where different
policies apply to different sectors.  The configuration of such a
behavior, as well as any other configuration applicable to such an RD
(i.e. the set of recognized authorities) is out of scope for this
document.
Paragraph (version B):
Endpoint authorization needs to be checked on registration and
registration resource operations independently of whether there are
configured requirements on the credentials for a given endpoint name
(and sector; secure-ep) or whether arbitrary names are accepted
(arbitrary-ep).
Paragraph (version B):
Simple registration could be used to circumvent address-based access
control: An attacker would send a simple registration request with
the victim's address as source address, and later look up the
victim's /.well-known/core content in the RD.  Mitigation for this is
recommended in simple.
Paragraph (version B):
The Registration Resource path is visible to any client that is
allowed endpoint lookup, and can be extracted by resource lookup
clients as well.  The same goes for registration attributes that are
shown as target attributes or lookup attributes.  The RD needs to
consider this in the choice of Registration Resource paths, and
administrators or endpoint in their choice of attributes.
Paragraph (version B):
When alterations to registration attributes are reordered, an
attacker may create any combination of attributes ever set, with
the attack difficulty determined by the security layer's replay
properties.
Paragraph (version B):
For example, if example-freshness were conducted without freshness
assurances, an attacker could later reset the lifetime back to
7200.  Thus, the device is made unreachable to lookup clients.
Paragraph (version B):
When registration updates without query parameters (which just
serve to restart the lifetime) can be reordered, an attacker can
use intercepted messages to give the appearance of the device
being alive to the RD.
Paragraph (version B):
This is unacceptable when when the RD's security policy promises
reachability of endpoints (e.g. when disappearing devices would
trigger further investigation), but may be acceptable with other
policies.
Paragraph (version A):
Minor editorial fixes in response to Gen-ART review.
Paragraph (version A):
Random EP names: Point that multiple collisions are possible but
unlikely.
Paragraph (version B):
Clarify that the mapping between endpoint names and subject
fields is up to a policy that defines reliance on names, and
give an example.
Paragraph (version B):
Random EP names: Point that multiple collisions are possible
but unlikely.
Paragraph (version B):
RD replication: Point out that policies may limit that.
Paragraph (version B):
Registration: Reword (ep, d) mapping to a previous
registration's resource that could have been read as another
endpoint taking over an existing registration.
Paragraph (version B):
Clarify that the security policy is a property of the RD the
any client may need to verify by checking the RD's
authorization.
Paragraph (version A):
Shorten amplification mitigation by removing the references to
earlier cases of DDoS amplification, and by removing
redundancies between the problem introduction and the
description of how an RD could become part of the problem.
Paragraph (version A):
Acknowledge that most discovery operations are not secured;
mention consequences and mitigation.
Paragraph (version B):
Add note about information in Registration Resource path.
Paragraph (version B):
Acknowledge that most host discovery operations are not
secured; mention consequences and mitigation.
Paragraph (version B):
Drop the previously stated assumption that RDAO and any DHCP
options would only be used together with SLAAC and DHCP for
address configuration, respectivly.
Paragraph (version B):
Clarify that it is an option for RAs and not other ND
messages.
Paragraph (version B):
Change Lifetime from 16-bit minutes to 32-bit seconds and
swap it with Reserved (aligning it with RDNSS which it
shares other properties as well).
Paragraph (version B):
Wording around "mostly mandatory" has been improved, conflicts
clarified and sector default selection adjusted.
Paragraph (version A):
Registration: Wording around "mostly mandatory" has been improved,
conflicts clarified and sector default selection adjusted.
Paragraph (version A):
RD replication: Point out that security policies may limit that.
Paragraph (version A):
Clarify that with all security policies, clients must verify
the authorization of the RD.
Paragraph (version B):
M2M: Move system design paragraph towards the topic of
reusability.
Paragraph (version B):
Various editorial fixes in response to Gen-ART and IESG reviews.
Paragraph (version B):
Terminology: Clarify that the CTs' installation events can occur
multiple times.