draft-ietf-core-echo-request-tag-09.txt   draft-ietf-core-echo-request-tag-10.txt 
CoRE Working Group C. Amsuess CoRE Working Group C. Amsuess
Internet-Draft Internet-Draft
Updates: 7252 (if approved) J. Mattsson Updates: 7252 (if approved) J. Mattsson
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: September 10, 2020 Ericsson AB Expires: January 14, 2021 Ericsson AB
March 09, 2020 July 13, 2020
CoAP: Echo, Request-Tag, and Token Processing CoAP: Echo, Request-Tag, and Token Processing
draft-ietf-core-echo-request-tag-09 draft-ietf-core-echo-request-tag-10
Abstract Abstract
This document specifies enhancements to the Constrained Application This document specifies enhancements to the Constrained Application
Protocol (CoAP) that mitigate security issues in particular use Protocol (CoAP) that mitigate security issues in particular use
cases. The Echo option enables a CoAP server to verify the freshness cases. The Echo option enables a CoAP server to verify the freshness
of a request or to force a client to demonstrate reachability at its of a request or to force a client to demonstrate reachability at its
claimed network address; it is now the recommeded way to mitigate claimed network address. The Request-Tag option allows the CoAP
amplification attacks. The Request-Tag option allows the CoAP server server to match block-wise message fragments belonging to the same
to match block-wise message fragments belonging to the same request. request. This document updates RFC7252 with respect to the client
The update to the client Token processing requirements of RFC 7252 Token processing requirements, forbidding non-secure reuse of Tokens
forbids non-secure reuse of Tokens to ensure binding of responses to to ensure binding of response to request when CoAP is used with
requests when CoAP is used with security. security, and with respect to amplification mitigation, where the use
of Echo is now recommended.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 35
3. Protecting Message Bodies using Request Tags . . . . . . . . 11 3. Protecting Message Bodies using Request Tags . . . . . . . . 11
3.1. Fragmented Message Body Integrity . . . . . . . . . . . . 11 3.1. Fragmented Message Body Integrity . . . . . . . . . . . . 11
3.2. The Request-Tag Option . . . . . . . . . . . . . . . . . 12 3.2. The Request-Tag Option . . . . . . . . . . . . . . . . . 12
3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 12 3.2.1. Request-Tag Option Format . . . . . . . . . . . . . . 12
3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 13 3.3. Request-Tag Processing by Servers . . . . . . . . . . . . 13
3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 14 3.4. Setting the Request-Tag . . . . . . . . . . . . . . . . . 14
3.5. Applications of the Request-Tag Option . . . . . . . . . 15 3.5. Applications of the Request-Tag Option . . . . . . . . . 15
3.5.1. Body Integrity Based on Payload Integrity . . . . . . 15 3.5.1. Body Integrity Based on Payload Integrity . . . . . . 15
3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 16 3.5.2. Multiple Concurrent Block-wise Operations . . . . . . 16
3.5.3. Simplified Block-Wise Handling for Constrained 3.5.3. Simplified Block-Wise Handling for Constrained
Proxies . . . . . . . . . . . . . . . . . . . . . . . 16 Proxies . . . . . . . . . . . . . . . . . . . . . . . 17
3.6. Rationale for the Option Properties . . . . . . . . . . . 17 3.6. Rationale for the Option Properties . . . . . . . . . . . 17
3.7. Rationale for Introducing the Option . . . . . . . . . . 17 3.7. Rationale for Introducing the Option . . . . . . . . . . 17
3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 18 3.8. Block2 / ETag Processing . . . . . . . . . . . . . . . . 18
4. Token Processing for Secure Request-Response Binding . . . . 18 4. Token Processing for Secure Request-Response Binding . . . . 18
4.1. Request-Response Binding . . . . . . . . . . . . . . . . 18 4.1. Request-Response Binding . . . . . . . . . . . . . . . . 18
4.2. Updated Token Processing Requirements for Clients . . . . 19 4.2. Updated Token Processing Requirements for Clients . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Token reuse . . . . . . . . . . . . . . . . . . . . . . . 20
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Methods for Generating Echo Option Values . . . . . 24 Appendix A. Methods for Generating Echo Option Values . . . . . 24
Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 25 Appendix B. Request-Tag Message Size Impact . . . . . . . . . . 26
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The initial Constrained Application Protocol (CoAP) suite of The initial Constrained Application Protocol (CoAP) suite of
specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed specifications ([RFC7252], [RFC7641], and [RFC7959]) was designed
with the assumption that security could be provided on a separate with the assumption that security could be provided on a separate
layer, in particular by using DTLS ([RFC6347]). However, for some layer, in particular by using DTLS ([RFC6347]). However, for some
use cases, additional functionality or extra processing is needed to use cases, additional functionality or extra processing is needed to
support secure CoAP operations. This document specifies security support secure CoAP operations. This document specifies security
enhancements to the Constrained Application Protocol (CoAP). enhancements to the Constrained Application Protocol (CoAP).
skipping to change at page 5, line 9 skipping to change at page 5, line 12
when the client made the request. In a general hop-by-hop setting, when the client made the request. In a general hop-by-hop setting,
freshness may need to be verified in each hop. freshness may need to be verified in each hop.
A straightforward mitigation of potential delayed requests is that A straightforward mitigation of potential delayed requests is that
the CoAP server rejects a request the first time it appears and asks the CoAP server rejects a request the first time it appears and asks
the CoAP client to prove that it intended to make the request at this the CoAP client to prove that it intended to make the request at this
point in time. point in time.
2.2. The Echo Option 2.2. The Echo Option
This document defines the Echo option, a a lightweight challenge- This document defines the Echo option, a lightweight challenge-
response mechanism for CoAP that enables a CoAP server to verify the response mechanism for CoAP that enables a CoAP server to verify the
freshness of a request. A fresh request is one whose age has not yet freshness of a request. A fresh request is one whose age has not yet
exceeded the freshness requirements set by the server. The freshness exceeded the freshness requirements set by the server. The freshness
requirements are application specific and may vary based on resource, requirements are application specific and may vary based on resource,
method, and parameters outside of CoAP such as policies. The Echo method, and parameters outside of CoAP such as policies. The Echo
option value is a challenge from the server to the client included in option value is a challenge from the server to the client included in
a CoAP response and echoed back to the server in one or more CoAP a CoAP response and echoed back to the server in one or more CoAP
requests. The Echo option provides a convention to transfer requests. The Echo option provides a convention to transfer
freshness indicators that works for all CoAP methods and response freshness indicators that works for all CoAP methods and response
codes. codes.
skipping to change at page 5, line 41 skipping to change at page 5, line 44
2.2.1. Echo Option Format 2.2.1. Echo Option Format
The Echo Option is elective, safe-to-forward, not part of the cache- The Echo Option is elective, safe-to-forward, not part of the cache-
key, and not repeatable, see Figure 1, which extends Table 4 of key, and not repeatable, see Figure 1, which extends Table 4 of
[RFC7252]). [RFC7252]).
+--------+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+---+---+
| No. | C | U | N | R | Name | Format | Len. | Default | E | U | | No. | C | U | N | R | Name | Format | Len. | Default | E | U |
+--------+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+---+---+
| TBD248 | | | x | | Echo | opaque | 1-40 | (none) | x | x | | TBD252 | | | x | | Echo | opaque | 1-40 | (none) | x | x |
+--------+---+---+---+---+-------------+--------+------+---------+---+---+ +--------+---+---+---+---+-------------+--------+------+---------+---+---+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable,
E = Encrypt and Integrity Protect (when using OSCORE) E = Encrypt and Integrity Protect (when using OSCORE)
Figure 1: Echo Option Summary Figure 1: Echo Option Summary
The Echo option value is generated by a server, and its content and The Echo option value is generated by a server, and its content and
structure are implementation specific. Different methods for structure are implementation specific. Different methods for
generating Echo option values are outlined in Appendix A. Clients generating Echo option values are outlined in Appendix A. Clients
skipping to change at page 9, line 39 skipping to change at page 9, line 39
and state synchronizing), the Echo option value MUST be integrity and state synchronizing), the Echo option value MUST be integrity
protected between the intended endpoints, e.g. using DTLS, TLS, or an protected between the intended endpoints, e.g. using DTLS, TLS, or an
OSCORE Inner option ([RFC8613]). When used to demonstrate OSCORE Inner option ([RFC8613]). When used to demonstrate
reachability at a claimed network address, the Echo option SHOULD reachability at a claimed network address, the Echo option SHOULD
contain the client's network address, but MAY be unprotected. contain the client's network address, but MAY be unprotected.
A CoAP-to-CoAP proxy MAY set an Echo option on responses, both on A CoAP-to-CoAP proxy MAY set an Echo option on responses, both on
forwarded ones that had no Echo option or ones generated by the proxy forwarded ones that had no Echo option or ones generated by the proxy
(from cache or as an error). If it does so, it MUST remove the Echo (from cache or as an error). If it does so, it MUST remove the Echo
option it recognizes as one generated by itself on follow-up option it recognizes as one generated by itself on follow-up
requests. However, it MUST relay the Echo option of responses requests. When it receives an Echo option in a response, it may
unmodified, and MUST relay the Echo option of requests it does not forward it to the client (and, not recognizing it as an own in future
recognize as generated by itself unmodified. requests, relay it in the other direction as well) or process it on
its own. If it does so, it MUST ensure that the client's request was
generated (or is re-generated) after the Echo value used to send to
the server was first seen. (In most cases, this means that the proxy
needs to ask the client to repeat the request with a new Echo value).
The CoAP server side of CoAP-to-HTTP proxies MAY request freshness, The CoAP server side of CoAP-to-HTTP proxies MAY request freshness,
especially if they have reason to assume that access may require it especially if they have reason to assume that access may require it
(e.g. because it is a PUT or POST); how this is determined is out of (e.g. because it is a PUT or POST); how this is determined is out of
scope for this document. The CoAP client side of HTTP-to-CoAP scope for this document. The CoAP client side of HTTP-to-CoAP
proxies SHOULD respond to Echo challenges themselves if they know proxies SHOULD respond to Echo challenges themselves if they know
from the recent establishing of the connection that the HTTP request from the recent establishing of the connection that the HTTP request
is fresh. Otherwise, they SHOULD respond with 503 Service is fresh. Otherwise, they SHOULD respond with 503 Service
Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive
connection. They MAY also use other mechanisms to establish connection. If the HTTP request arrived in Early Data, the proxy
freshness of the HTTP request that are not specified here. SHOULD use a 425 Too Early response instead (see [RFC8470]). They
MAY also use other mechanisms to establish freshness of the HTTP
request that are not specified here.
2.4. Applications of the Echo Option 2.4. Applications of the Echo Option
1. Actuation requests often require freshness guarantees to avoid 1. Actuation requests often require freshness guarantees to avoid
accidental or malicious delayed actuator actions. In general, accidental or malicious delayed actuator actions. In general,
all non-safe methods (e.g. POST, PUT, DELETE) may require all non-safe methods (e.g. POST, PUT, DELETE) may require
freshness guarantees for secure operation. freshness guarantees for secure operation.
* The same Echo value may be used for multiple actuation * The same Echo value may be used for multiple actuation
requests to the same server, as long as the total round-trip requests to the same server, as long as the total round-trip
skipping to change at page 10, line 46 skipping to change at page 11, line 4
For example, with OSCORE it is possible to reuse a partly For example, with OSCORE it is possible to reuse a partly
persistently stored security context by synchronizing the persistently stored security context by synchronizing the
Partial IV (sequence number) using the Echo option, see Partial IV (sequence number) using the Echo option, see
Section 7.5 of [RFC8613]. Section 7.5 of [RFC8613].
* A device joining a CoAP group communication [RFC7390] * A device joining a CoAP group communication [RFC7390]
protected with OSCORE [I-D.ietf-core-oscore-groupcomm] may be protected with OSCORE [I-D.ietf-core-oscore-groupcomm] may be
required to initially verify freshness and synchronize state required to initially verify freshness and synchronize state
or time with a client by using the Echo option in a unicast or time with a client by using the Echo option in a unicast
response to a multicast request. The client receiving the response to a multicast request. The client receiving the
response with the Echo option includes the Echo option with response with the Echo option includes the Echo value in a
the same value in a request, either in a unicast request to subsequent unicast request to the responding server.
the responding server, or in a subsequent group request. In
the latter case, the Echo option will be ignored except by the
responding server.
3. A server that sends large responses to unauthenticated peers 3. A server that sends large responses to unauthenticated peers
SHOULD mitigate amplification attacks such as described in SHOULD mitigate amplification attacks such as described in
Section 11.3 of [RFC7252] (where an attacker would put a victim's Section 11.3 of [RFC7252] (where an attacker would put a victim's
address in the source address of a CoAP request). The address in the source address of a CoAP request). The
RECOMMENDED way to do this is to ask a client to Echo its request RECOMMENDED way to do this is to ask a client to Echo its request
to verify its source address. This needs to be done only once to verify its source address. This needs to be done only once
per peer and limits the range of potential victims from the per peer and limits the range of potential victims from the
general Internet to endpoints that have been previously in general Internet to endpoints that have been previously in
contact with the server. For this application, the Echo option contact with the server. For this application, the Echo option
skipping to change at page 11, line 26 skipping to change at page 11, line 28
* In the presence of a proxy, a server will not be able to * In the presence of a proxy, a server will not be able to
distinguish different origin client endpoints. Following from distinguish different origin client endpoints. Following from
the recommendation above, a proxy that sends large responses the recommendation above, a proxy that sends large responses
to unauthenticated peers SHOULD mitigate amplification to unauthenticated peers SHOULD mitigate amplification
attacks. The proxy SHOULD use Echo to verify origin attacks. The proxy SHOULD use Echo to verify origin
reachability as described in Section 2.3. The proxy MAY reachability as described in Section 2.3. The proxy MAY
forward idempotent requests immediately to have a cached forward idempotent requests immediately to have a cached
result available when the client's Echoed request arrives. result available when the client's Echoed request arrives.
* Amplification mitigation should be used when the the response * Amplification mitigation should be used when the response
would be more than three times the size of the request, would be more than three times the size of the request,
considering the complete frame on the wire as it is typically considering the complete frame on the wire as it is typically
sent across the Internet. In practice, this allows UDP data sent across the Internet. In practice, this allows UDP data
of at least 152 Bytes without further checks. of at least 152 Bytes without further checks.
* When an Echo response is sent to mitigate amplification, it * When an Echo response is sent to mitigate amplification, it
MUST be sent as a piggybacked or non-confirmable response, MUST be sent as a piggybacked or non-confirmable response,
never as a separate one (which would cause amplification due never as a separate one (which would cause amplification due
to retransmission). to retransmission).
skipping to change at page 16, line 24 skipping to change at page 16, line 24
rely on a conforming client to set the Request-Tag option when rely on a conforming client to set the Request-Tag option when
required, and thereby conclude on the integrity of the assembled required, and thereby conclude on the integrity of the assembled
body. body.
Note that this mechanism is implicitly implemented when the security Note that this mechanism is implicitly implemented when the security
layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]). layer guarantees ordered delivery (e.g. CoAP over TLS [RFC8323]).
This is because with each message, any earlier message can not be This is because with each message, any earlier message can not be
replayed any more, so the client never needs to set the Request-Tag replayed any more, so the client never needs to set the Request-Tag
option unless it wants to perform concurrent operations. option unless it wants to perform concurrent operations.
Body integrity only makes sense in applications that have stateful
block-wise transfers. On applications where all the state is in the
application (e.g. because rather than POSTing a large representation
to a collection in a stateful block-wise transfer, a collection item
is created first, then written to once and available when written
completely), clients need not concern themselves with body integrity
and thus the Request-Tag.
3.5.2. Multiple Concurrent Block-wise Operations 3.5.2. Multiple Concurrent Block-wise Operations
CoAP clients, especially CoAP proxies, may initiate a block-wise CoAP clients, especially CoAP proxies, may initiate a block-wise
request operation to a resource, to which a previous one is already request operation to a resource, to which a previous one is already
in progress, which the new request should not cancel. A CoAP proxy in progress, which the new request should not cancel. A CoAP proxy
would be in such a situation when it forwards operations with the would be in such a situation when it forwards operations with the
same cache-key options but possibly different payloads. same cache-key options but possibly different payloads.
For those cases, Request-Tag is the proxy-safe elective option For those cases, Request-Tag is the proxy-safe elective option
suggested in [RFC7959] Section 2.4 last paragraph. suggested in [RFC7959] Section 2.4 last paragraph.
skipping to change at page 20, line 50 skipping to change at page 21, line 7
Integrity Protected Timestamp method described in Appendix A. Integrity Protected Timestamp method described in Appendix A.
5.1. Token reuse 5.1. Token reuse
Reusing Tokens in a way so that responses are guaranteed to not be Reusing Tokens in a way so that responses are guaranteed to not be
associated with the wrong request is not trivial as on-path attackers associated with the wrong request is not trivial as on-path attackers
may block, delay, and reorder messages, requests may be sent to may block, delay, and reorder messages, requests may be sent to
several servers, and servers may process requests in any order and several servers, and servers may process requests in any order and
send many responses to the same request. The use of a sequence send many responses to the same request. The use of a sequence
number is therefore recommended when CoAP is used with a security number is therefore recommended when CoAP is used with a security
protocol that does not providing bindings between requests and protocol that does not provide bindings between requests and
responses such as DTLS or TLS. responses such as DTLS or TLS.
For a generic response to a confirmable request over DTLS, binding For a generic response to a confirmable request over DTLS, binding
can only be claimed without out-of-band knowledge if can only be claimed without out-of-band knowledge if
o the original request was never retransmitted, o the original request was never retransmitted,
o the response was piggybacked in an Acknowledgement message (as a o the response was piggybacked in an Acknowledgement message (as a
confirmable or non-confirmable response may have been transmitted confirmable or non-confirmable response may have been transmitted
multiple times), and multiple times), and
skipping to change at page 22, line 13 skipping to change at page 22, line 19
reveal information about the server such as location or time since reveal information about the server such as location or time since
reboot, or that the server will accept expired certificates. reboot, or that the server will accept expired certificates.
Timestamps MAY be used if Echo is encrypted between the client and Timestamps MAY be used if Echo is encrypted between the client and
the server, e.g. in the case of DTLS without proxies or when using the server, e.g. in the case of DTLS without proxies or when using
OSCORE with an Inner Echo option. OSCORE with an Inner Echo option.
Like HTTP cookies, the Echo option could potentially be abused as a Like HTTP cookies, the Echo option could potentially be abused as a
tracking mechanism to link to different requests to the same client. tracking mechanism to link to different requests to the same client.
This is especially true for pre-emptive Echo values. Servers MUST This is especially true for pre-emptive Echo values. Servers MUST
NOT use the Echo option to correlate requests for other purposes than NOT use the Echo option to correlate requests for other purposes than
freshness and reachability. Clients only send Echo to the same from freshness and reachability. Clients only send Echo to the same
which they were received. Compared to HTTP, CoAP clients are often server from which they were received. Compared to HTTP, CoAP clients
authenticated and non-mobile, and servers can therefore often are often authenticated and non-mobile, and servers can therefore
correlate requests based on the security context, the client often correlate requests based on the security context, the client
credentials, or the network address. When the Echo option increases credentials, or the network address. Especially when the Echo option
a server's ability to correlate requests, clients MAY discard all increases a server's ability to correlate requests, clients MAY
pre-emptive Echo values. discard all pre-emptive Echo values.
7. IANA Considerations 7. IANA Considerations
IANA is requested to add the following option numbers to the "CoAP IANA is requested to add the following option numbers to the "CoAP
Option Numbers" registry defined by [RFC7252]: Option Numbers" registry defined by [RFC7252]:
[ [
The editor is asked to suggest the numbers after TBD, as those satisfy the construction requirements set out in RFC7252: The editor is asked to suggest the numbers after TBD, as those
Echo is NoCacheKey but not Unsafe or Critical, so it needs to end with 11100 in binary representation; satisfy the construction requirements set out in RFC7252: Echo is
Request-Tag has no properties so it needs to end with 00 and not with 11100). NoCacheKey but not Unsafe or Critical, so it needs to end with 11100
in binary representation; Request-Tag has no properties so it needs
to end with 00 and not with 11100).
Request-Tag are picked to not waste the precious space of less-than-one-byte options, Request-Tag was picked to not waste the precious space of less-than-
but such that its offset from the Block1 option it regularly occurs with can still be expressed in an 1-byte offset (27 + (13 + 255) > 292). one-byte options, but such that its offset from the Block1 option it
regularly occurs with can still be expressed in an 1-byte offset (27
+ (13 + 255) > 292).
Echo was picked to be the shortest it can be in an empty message as a NoCacheKey option Echo was picked to be the shortest it can be in an empty message as a
(11100 in binary does not fit in a nibble, and two lower ones are already taken), NoCacheKey option (11100 in binary does not fit in a nibble, and two
and as high as possible to keep room for other options that might typically occur in pairs and might still use optimization around low numbers. lower ones are already taken), and as high as possible to keep room
for other options that might typically occur in pairs and might still
use optimization around low numbers.
] ]
+--------+-------------+-------------------+ +--------+-------------+-------------------+
| Number | Name | Reference | | Number | Name | Reference |
+--------+-------------+-------------------+ +--------+-------------+-------------------+
| TBD248 | Echo | [[this document]] | | TBD252 | Echo | [[this document]] |
| | | | | | | |
| TBD292 | Request-Tag | [[this document]] | | TBD292 | Request-Tag | [[this document]] |
+--------+-------------+-------------------+ +--------+-------------+-------------------+
Figure 5: CoAP Option Numbers Figure 5: CoAP Option Numbers
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 23, line 33 skipping to change at page 23, line 42
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", "Group OSCORE - Secure Group Communication for CoAP",
draft-ietf-core-oscore-groupcomm-06 (work in progress), draft-ietf-core-oscore-groupcomm-09 (work in progress),
November 2019. June 2020.
[I-D.ietf-core-stateless] [I-D.ietf-core-stateless]
Hartke, K., "Extended Tokens and Stateless Clients in the Hartke, K., "Extended Tokens and Stateless Clients in the
Constrained Application Protocol (CoAP)", draft-ietf-core- Constrained Application Protocol (CoAP)", draft-ietf-core-
stateless-04 (work in progress), December 2019. stateless-06 (work in progress), April 2020.
[I-D.mattsson-core-coap-actuators] [I-D.mattsson-core-coap-actuators]
Mattsson, J., Fornehed, J., Selander, G., Palombini, F., Mattsson, J., Fornehed, J., Selander, G., Palombini, F.,
and C. Amsuess, "Controlling Actuators with CoAP", draft- and C. Amsuess, "Controlling Actuators with CoAP", draft-
mattsson-core-coap-actuators-06 (work in progress), mattsson-core-coap-actuators-06 (work in progress),
September 2018. September 2018.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
skipping to change at page 24, line 25 skipping to change at page 24, line 35
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018, RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/info/rfc8323>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
Appendix A. Methods for Generating Echo Option Values Appendix A. Methods for Generating Echo Option Values
The content and structure of the Echo option value are implementation The content and structure of the Echo option value are implementation
specific and determined by the server. Two simple mechanisms for specific and determined by the server. Two simple mechanisms for
time-based freshness are outlined in this section, the first is time-based freshness are outlined in this section, the first is
skipping to change at page 26, line 26 skipping to change at page 26, line 39
o In OSCORE, the sequence number can be artificially increased so o In OSCORE, the sequence number can be artificially increased so
that all lost messages are outside of the replay window by the that all lost messages are outside of the replay window by the
time the first request of the new operation gets processed, and time the first request of the new operation gets processed, and
all earlier operations can therefore be regarded as concluded. all earlier operations can therefore be regarded as concluded.
Appendix C. Change Log Appendix C. Change Log
[ The editor is asked to remove this section before publication. ] [ The editor is asked to remove this section before publication. ]
o Changes since draft-ietf-core-echo-request-tag-09:
* Allow intermediaries to do Echo processing, provided they ask
at least as much freshness as they forward
* Emphasize that clients can forget Echo to further discourage
abuse as cookies
* Emphasize that RESTful application design can avoid the need
for a Request-Tag
* Align with core-oscore-groupcomm-09
* Add interaction with HTTP Early Data / 425 Too Early
* Abstract: Explicitly mention both updates to 7252
* Change requested option number of Echo to 252 (previous
property calculation was erroneous)
o Changes since draft-ietf-core-echo-request-tag-08: o Changes since draft-ietf-core-echo-request-tag-08:
* Make amplification attack mitigation by Echo an RFC7252 * Make amplification attack mitigation by Echo an RFC7252
updating recommendation updating recommendation
* Give some more concrete guidance to that use case in terms of * Give some more concrete guidance to that use case in terms of
sizes and message types sizes and message types
* Allow short (1-3 byte) Echo values for deterministic cases, * Allow short (1-3 byte) Echo values for deterministic cases,
with according security considerations with according security considerations
 End of changes. 26 change blocks. 
49 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/