draft-ietf-ace-coap-est-13.txt   draft-ietf-ace-coap-est-14.txt 
ACE P. van der Stok ACE P. van der Stok
Internet-Draft Consultant Internet-Draft Consultant
Intended status: Standards Track P. Kampanakis Intended status: Standards Track P. Kampanakis
Expires: March 13, 2020 Cisco Systems Expires: March 23, 2020 Cisco Systems
M. Richardson M. Richardson
SSW SSW
S. Raza S. Raza
RISE SICS RISE SICS
September 10, 2019 September 20, 2019
EST over secure CoAP (EST-coaps) EST over secure CoAP (EST-coaps)
draft-ietf-ace-coap-est-13 draft-ietf-ace-coap-est-14
Abstract Abstract
Enrollment over Secure Transport (EST) is used as a certificate Enrollment over Secure Transport (EST) is used as a certificate
provisioning protocol over HTTPS. Low-resource devices often use the provisioning protocol over HTTPS. Low-resource devices often use the
lightweight Constrained Application Protocol (CoAP) for message lightweight Constrained Application Protocol (CoAP) for message
exchanges. This document defines how to transport EST payloads over exchanges. This document defines how to transport EST payloads over
secure CoAP (EST-coaps), which allows constrained devices to use secure CoAP (EST-coaps), which allows constrained devices to use
existing EST functionality for provisioning certificates. existing EST functionality for provisioning certificates.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 March 13, 2020. This Internet-Draft will expire on March 23, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 27 skipping to change at page 2, line 27
5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 10 5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 10
5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12
5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 13 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 13
5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 14 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 14
5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 15 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 15
5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 16 5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 16
5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 17 5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 17
5.8. Server-side Key Generation . . . . . . . . . . . . . . . 19 5.8. Server-side Key Generation . . . . . . . . . . . . . . . 19
6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 21 6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 21
7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Deployment limitations . . . . . . . . . . . . . . . . . . . 23 8. Deployment limitations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 24 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 24
9.2. Resource Type registry . . . . . . . . . . . . . . . . . 24 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10.1. EST server considerations . . . . . . . . . . . . . . . 25 10.1. EST server considerations . . . . . . . . . . . . . . . 25
10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 27 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 27
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . 30 13.2. Informative References . . . . . . . . . . . . . . . . . 30
skipping to change at page 3, line 11 skipping to change at page 3, line 11
C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 44 C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 45 C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 45
C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 47 C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Change Log 1. Change Log
EDNOTE: Remove this section before publication EDNOTE: Remove this section before publication
-14
Updates to complete Ben's AD review feedback and discussions.
-13 -13
Updates based on AD's review and discussions Updates based on AD's review and discussions
Examples redone without password Examples redone without password
-12 -12
Updated section 5 based on Esko's comments and nits identified. Updated section 5 based on Esko's comments and nits identified.
skipping to change at page 10, line 27 skipping to change at page 10, line 29
o Server-side key generation messages to provide a client identity o Server-side key generation messages to provide a client identity
private key when the client chooses so. private key when the client chooses so.
While [RFC7030] permits a number of the EST functions to be used While [RFC7030] permits a number of the EST functions to be used
without authentication, this specification requires that the client without authentication, this specification requires that the client
MUST be authenticated for all functions. MUST be authenticated for all functions.
5.1. Discovery and URIs 5.1. Discovery and URIs
EST-coaps is targeted for low-resource networks with small packets. EST-coaps is targeted for low-resource networks with small packets.
Two types of installations are possible (1)rigid ones where the Two types of installations are possible (1) rigid ones where the
address and the supported functions of the EST server(s) are known, address and the supported functions of the EST server(s) are known,
and (2) flexible one where the EST server and it supported functions and (2) flexible one where the EST server and it supported functions
need to be discovered. need to be discovered.
For both types of installations, saving header space is important and For both types of installations, saving header space is important and
short EST-coaps URIs are specified in this document. These URIs are short EST-coaps URIs are specified in this document. These URIs are
shorter than the ones in [RFC7030]. Two example EST-coaps resource shorter than the ones in [RFC7030]. Two example EST-coaps resource
path names are: path names are:
coaps://example.com:<port>/.well-known/est/<short-est> coaps://example.com:<port>/.well-known/est/<short-est>
skipping to change at page 11, line 25 skipping to change at page 11, line 29
| /serverkeygen | /skg (PKCS#7) | | /serverkeygen | /skg (PKCS#7) |
| /serverkeygen | /skc (application/pkix-cert) | | /serverkeygen | /skc (application/pkix-cert) |
| /csrattrs | /att | | /csrattrs | /att |
+------------------+------------------------------+ +------------------+------------------------------+
Table 1: Short EST-coaps URI path Table 1: Short EST-coaps URI path
The /skg message is the EST /serverkeygen equivalent where the client The /skg message is the EST /serverkeygen equivalent where the client
requests a certificate in PKCS#7 format and a private key. If the requests a certificate in PKCS#7 format and a private key. If the
client prefers a single application/pkix-cert certificate instead of client prefers a single application/pkix-cert certificate instead of
PKCS#7, she will make an /skc request. In both cases a private key PKCS#7, she will make an /skc request. In both cases (i.e., /skg,
MUST be returned /skc) a private key MUST be returned
Clients and servers MUST support the short resource EST-coaps URIs. Clients and servers MUST support the short resource EST-coaps URIs.
The corresponding longer URIs from [RFC7030] MAY be supported.
In the context of CoAP, the presence and location of (path to) the In the context of CoAP, the presence and location of (path to) the
EST resources are discovered by sending a GET request to "/.well- EST resources are discovered by sending a GET request to "/.well-
known/core" including a resource type (RT) parameter with the value known/core" including a resource type (RT) parameter with the value
"ace.est*" [RFC6690]. The example below shows the discovery over "ace.est*" [RFC6690]. The example below shows the discovery over
CoAPS of the presence and location of EST-coaps resources. Linefeeds CoAPS of the presence and location of EST-coaps resources. Linefeeds
are included only for readability. are included only for readability.
REQ: GET /.well-known/core?rt=ace.est* REQ: GET /.well-known/core?rt=ace.est*
skipping to change at page 12, line 5 skipping to change at page 12, line 8
</est/att>;rt="ace.est.att";ct=285, </est/att>;rt="ace.est.att";ct=285,
</est/skg>;rt="ace.est.skg";ct=62, </est/skg>;rt="ace.est.skg";ct=62,
</est/skc>;rt="ace.est.skc";ct=62 </est/skc>;rt="ace.est.skc";ct=62
The first three lines, describing ace.est.crts, ace.est.sen, and The first three lines, describing ace.est.crts, ace.est.sen, and
ace.est.sren, of the discovery response above MUST be returned if the ace.est.sren, of the discovery response above MUST be returned if the
server supports resource discovery. The last three lines are only server supports resource discovery. The last three lines are only
included if the corresponding EST functions are implemented (see included if the corresponding EST functions are implemented (see
Table 2). The Content-Formats in the response allow the client to Table 2). The Content-Formats in the response allow the client to
request one that is supported by the server. These are the values request one that is supported by the server. These are the values
that would be sent in the client request with an Accept option. This that would be sent in the client request with an Accept option.
approach allows future servers to incorporate currently not specified
content-formats and resources.
Discoverable port numbers can be returned in the response payload. Discoverable port numbers can be returned in the response payload.
An example response payload for non-default CoAPS server port 61617 An example response payload for non-default CoAPS server port 61617
follows below. Linefeeds are included only for readability. follows below. Linefeeds are included only for readability.
REQ: GET /.well-known/core?rt=ace.est* REQ: GET /.well-known/core?rt=ace.est*
RES: 2.05 Content RES: 2.05 Content
<coaps://[2001:db8:3::123]:61617/est/crts>;rt="ace.est.crts"; <coaps://[2001:db8:3::123]:61617/est/crts>;rt="ace.est.crts";
ct="281 TBD287", ct="281 TBD287",
skipping to change at page 19, line 19 skipping to change at page 19, line 19
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
<-- (ACK) (1:N1/0/256) (5.03 Service Unavailable) (Max-Age) <-- (ACK) (1:N1/0/256) (5.03 Service Unavailable) (Max-Age)
| |
| |
... Client tries again after Max-Age with identical payload ... ... Client tries again after Max-Age with identical payload ...
| |
| |
POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# 1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:0/1/256){CSR (frag# 1)}-->
<-- (ACK) (1:0/1/256) (2.31 Continue) <-- (ACK) (1:0/1/256) (2.31 Continue)
POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} -->
<-- (ACK) (1:1/1/256) (2.31 Continue) <-- (ACK) (1:1/1/256) (2.31 Continue)
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
| |
... Immediate response when certificate is ready ... ... Immediate response when certificate is ready ...
| |
<-- (ACK) (1:N1/0/256) (2:0/1/128) (2.04 Changed){Cert resp (frag# 1)} <-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)}
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) -->
<-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)} <-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)}
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) -->
<-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp (frag# N2+1)} <-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp (frag# N2+1)}
Figure 3: EST-COAP enrollment with long wait Figure 3: EST-COAP enrollment with long wait
skipping to change at page 20, line 33 skipping to change at page 20, line 33
or the asymmetric keypair establishment method is out of scope of the or the asymmetric keypair establishment method is out of scope of the
specification. A /skg or /skc request with a CSR without specification. A /skg or /skc request with a CSR without
SMIMECapabilities expects an application/multipart-core with an SMIMECapabilities expects an application/multipart-core with an
unencrypted PKCS#8 private key with Content-Format 284. unencrypted PKCS#8 private key with Content-Format 284.
The EST-coaps server-side key generation response is returned with The EST-coaps server-side key generation response is returned with
Content-Format application/multipart-core Content-Format application/multipart-core
[I-D.ietf-core-multipart-ct] containing a CBOR array with four items [I-D.ietf-core-multipart-ct] containing a CBOR array with four items
(Section 5.3) . The two representations (each consisting of two CBOR (Section 5.3) . The two representations (each consisting of two CBOR
array items) are preceded by its Content-Format ID. Dependent on the array items) are preceded by its Content-Format ID. Dependent on the
contents of the CSR, the private key can be in unprotected PKCS#8 request, the private key can be in unprotected PKCS#8 [RFC5958]
[RFC5958] format (Content-Format 284) or protected inside of CMS format (Content-Format 284) or protected inside of CMS SignedData
SignedData (Content-Format 280). The SignedData, placed in the (Content-Format 280). The SignedData, placed in the outermost
outermost container, is signed by the party that generated the container, is signed by the party that generated the private key,
private key, which may be the EST server or the EST CA. SignedData which may be the EST server or the EST CA. SignedData placed within
placed within the Enveloped Data does not need additional signing as the Enveloped Data does not need additional signing as explained in
explained in Section 4.4.2 of [RFC7030]. In summary, the Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted
symmetrically encrypted key is included in the encryptedKey attribute key is included in the encryptedKey attribute in a KEKRecipientInfo
in a KEKRecipientInfo structure. In the case where the asymmetric structure. In the case where the asymmetric encryption key is
encryption key is suitable for transport key operations the generated suitable for transport key operations the generated private key is
private key is encrypted with a symmetric key which is encrypted by encrypted with a symmetric key which is encrypted by the client-
the client-defined (in the CSR) asymmetric public key and is carried defined (in the CSR) asymmetric public key and is carried in an
in an encryptedKey attribute in a KeyTransRecipientInfo structure. encryptedKey attribute in a KeyTransRecipientInfo structure.
Finally, if the asymmetric encryption key is suitable for key Finally, if the asymmetric encryption key is suitable for key
agreement, the generated private key is encrypted with a symmetric agreement, the generated private key is encrypted with a symmetric
key which is encrypted by the client defined (in the CSR) asymmetric key which is encrypted by the client defined (in the CSR) asymmetric
public key and is carried in an recipientEncryptedKeys attribute in a public key and is carried in an recipientEncryptedKeys attribute in a
KeyAgreeRecipientInfo. KeyAgreeRecipientInfo.
[RFC7030] recommends the use of additional encryption of the returned [RFC7030] recommends the use of additional encryption of the returned
private key. For the context of this specification, clients and private key. For the context of this specification, clients and
servers that choose to support server-side key generation MUST servers that choose to support server-side key generation MUST
support unprotected (PKCS#8) private keys (Content-Format 284). support unprotected (PKCS#8) private keys (Content-Format 284).
Symmetric or asymmetric encryption of the private key (CMS Symmetric or asymmetric encryption of the private key (CMS
EnvelopedData, Content-Format 280) SHOULD be supported for EnvelopedData, Content-Format 280) SHOULD be supported for
deployments where end-to-end encryption needs to be provided between deployments where end-to-end encryption is needed between the client
the client and a server. Such cases could include architectures and a server. Such cases could include architectures where an entity
where an entity between the client and the CA terminates the DTLS between the client and the CA terminates the DTLS connection
connection (Registrar in Figure 4). (Registrar in Figure 4). This document does not strongly recommend
CMS encryption on top of the DTLS channel like [RFC7030] unless
Following [RFC7030]: "It is strongly RECOMMENDED that the clients mandated by the use-case.
request that the returned private key be afforded the additional
security of the Cryptographic Message Syntax (CMS) EnvelopedData in
addition to the TLS-provided security to protect against unauthorized
disclosure."
6. HTTPS-CoAPS Registrar 6. HTTPS-CoAPS Registrar
In real-world deployments, the EST server will not always reside In real-world deployments, the EST server will not always reside
within the CoAP boundary. The EST server can exist outside the within the CoAP boundary. The EST server can exist outside the
constrained network in which case it will support TLS/HTTP instead of constrained network in which case it will support TLS/HTTP instead of
CoAPS. In such environments EST-coaps is used by the client within CoAPS. In such environments EST-coaps is used by the client within
the CoAP boundary and TLS is used to transport the EST messages the CoAP boundary and TLS is used to transport the EST messages
outside the CoAP boundary. A Registrar at the edge is required to outside the CoAP boundary. A Registrar at the edge is required to
operate between the CoAP environment and the external HTTP network as operate between the CoAP environment and the external HTTP network as
skipping to change at page 22, line 22 skipping to change at page 22, line 20
the EST server when a Registrar is present. The EST server becomes the EST server when a Registrar is present. The EST server becomes
aware of the presence of a Registrar from its TLS client certificate aware of the presence of a Registrar from its TLS client certificate
that includes id-kp-cmcRA [RFC6402] extended key usage extension that includes id-kp-cmcRA [RFC6402] extended key usage extension
(EKU). As explained in Section 3.7 of [RFC7030], the "EST server (EKU). As explained in Section 3.7 of [RFC7030], the "EST server
SHOULD apply an authorization policy consistent with a Registrar SHOULD apply an authorization policy consistent with a Registrar
client. For example, it could be configured to accept PoP linking client. For example, it could be configured to accept PoP linking
information that does not match the current TLS session because the information that does not match the current TLS session because the
authenticated EST client Registrar has verified this information when authenticated EST client Registrar has verified this information when
acting as an EST server". acting as an EST server".
For some use cases, clients that leverage server-side key generation For some use-cases, clients that leverage server-side key generation
might prefer for the enrolled keys to be generated by the Registrar might prefer for the enrolled keys to be generated by the Registrar
if the CA does not support server-side key generation. Such a if the CA does not support server-side key generation. Such a
Registrar is responsible for generating a new CSR signed by a new key Registrar is responsible for generating a new CSR signed by a new key
which will be returned to the client along with the certificate from which will be returned to the client along with the certificate from
the CA. In these cases, the Registrar MUST use random number the CA. In these cases, the Registrar MUST use random number
generation with proper entropy. generation with proper entropy.
Table 1 contains the URI mappings between EST-coaps and EST that the Table 1 contains the URI mappings between EST-coaps and EST that the
Registrar MUST adhere to. Section 5.5 of this specification and Registrar MUST adhere to. Section 5.5 of this specification and
Section 7 of [RFC8075] define the mappings between EST-coaps and HTTP Section 7 of [RFC8075] define the mappings between EST-coaps and HTTP
skipping to change at page 23, line 17 skipping to change at page 23, line 11
This section addresses transmission parameters described in sections This section addresses transmission parameters described in sections
4.7 and 4.8 of [RFC7252]. EST does not impose any unique values on 4.7 and 4.8 of [RFC7252]. EST does not impose any unique values on
the CoAP parameters in [RFC7252], but the setting of the CoAP the CoAP parameters in [RFC7252], but the setting of the CoAP
parameter values may have consequence for the setting of the EST parameter values may have consequence for the setting of the EST
parameter values. parameter values.
It is recommended, based on experiments, to follow the default CoAP It is recommended, based on experiments, to follow the default CoAP
configuration parameters ([RFC7252]). However, depending on the configuration parameters ([RFC7252]). However, depending on the
implementation scenario, retransmissions and timeouts can also occur implementation scenario, retransmissions and timeouts can also occur
on other networking layers, governed by other configuration on other networking layers, governed by other configuration
parameters. When a change in a server parameter has been parameters. When a change in a server parameter has taken place, the
effectuated, the parameter values in the communicating endpoints MUST parameter values in the communicating endpoints MUST be adjusted as
be adjusted when necessary. necessary.
Some further comments about some specific parameters, mainly from Some further comments about some specific parameters, mainly from
Table 2 in [RFC7252]: Table 2 in [RFC7252]:
o NSTART: A parameter that controls the number of simultaneous o NSTART: A parameter that controls the number of simultaneous
outstanding interactions that a client maintains to a given outstanding interactions that a client maintains to a given
server. An EST-coaps client is expected to control at most one server. An EST-coaps client is expected to control at most one
interaction with a given server, which is the default NSTART value interaction with a given server, which is the default NSTART value
defined in [RFC7252]. defined in [RFC7252].
skipping to change at page 40, line 10 skipping to change at page 40, line 10
The following is an example of a cacerts exchange over DTLS. The The following is an example of a cacerts exchange over DTLS. The
content length of the cacerts response in appendix A.1 of [RFC7030] content length of the cacerts response in appendix A.1 of [RFC7030]
contains 639 bytes in binary in this example. The CoAP message adds contains 639 bytes in binary in this example. The CoAP message adds
around 10 bytes in this exmple, the DTLS record around 29 bytes. To around 10 bytes in this exmple, the DTLS record around 29 bytes. To
avoid IP fragmentation, the CoAP Block Option is used and an MTU of avoid IP fragmentation, the CoAP Block Option is used and an MTU of
127 is assumed to stay within one IEEE 802.15.4 packet. To stay 127 is assumed to stay within one IEEE 802.15.4 packet. To stay
below the MTU of 127, the payload is split in 9 packets with a below the MTU of 127, the payload is split in 9 packets with a
payload of 64 bytes each, followed by a last tenth packet of 63 payload of 64 bytes each, followed by a last tenth packet of 63
bytes. The client sends an IPv6 packet containing a UDP datagram bytes. The client sends an IPv6 packet containing a UDP datagram
with the DTLS record that encapsulates a CoAP request 10 times. The with DTLS record protection that encapsulates a CoAP request 10 times
server returns an IPv6 packet containing a UDP datagram with a DTLS (one fragment of the request per block). The server returns an IPv6
record that encapsulates the CoAP response. The CoAP request- packet containing a UDP datagram with the DTLS record that
response exchange with block option is shown below. Block Option is encapsulates the CoAP response. The CoAP request-response exchange
shown in a decomposed way (block-option:NUM/M/size) indicating the with block option is shown below. Block Option is shown in a
kind of Block Option (2 in this case) followed by a colon, and then decomposed way (block-option:NUM/M/size) indicating the kind of Block
the block number (NUM), the more bit (M = 0 in Block2 response means Option (2 in this case) followed by a colon, and then the block
it is last block), and block size with exponent (2**(SZX+4)) number (NUM), the more bit (M = 0 in Block2 response means it is last
separated by slashes. The Length 64 is used with SZX=2. The CoAP block), and block size with exponent (2**(SZX+4)) separated by
Request is sent confirmable (CON) and the Content-Format of the slashes. The Length 64 is used with SZX=2. The CoAP Request is sent
response, even though not shown, is 281 (application/pkcs7-mime; confirmable (CON) and the Content-Format of the response, even though
smime-type=certs-only). The transfer of the 10 blocks with partially not shown, is 281 (application/pkcs7-mime; smime-type=certs-only).
filled block NUM=9 is shown below The transfer of the 10 blocks with partially filled block NUM=9 is
shown below
GET example.com:9085/est/crts (2:0/0/64) --> GET example.com:9085/est/crts (2:0/0/64) -->
<-- (2:0/1/64) 2.05 Content <-- (2:0/1/64) 2.05 Content
GET example.com:9085/est/crts (2:1/0/64) --> GET example.com:9085/est/crts (2:1/0/64) -->
<-- (2:1/1/64) 2.05 Content <-- (2:1/1/64) 2.05 Content
| |
| |
| |
GET example.com:9085/est/crts (2:9/0/64) --> GET example.com:9085/est/crts (2:9/0/64) -->
<-- (2:9/0/64) 2.05 Content <-- (2:9/0/64) 2.05 Content
 End of changes. 18 change blocks. 
55 lines changed or deleted 53 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/