idnits 2.17.00 (12 Aug 2021) /tmp/idnits37032/draft-wang-core-profile-secflag-options-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 12, 2012) is 3507 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.fossati-core-publish-monitor-options' is defined on line 499, but no explicit reference was found in the text == Outdated reference: draft-ietf-core-coap has been published as RFC 7252 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE L. Wang 3 Internet-Draft W. Wang 4 Intended status: Informational BUPT 5 Expires: April 15, 2013 L. Zhu 6 F. Yu 7 Huawei Technologies 8 October 12, 2012 10 CoAP Option Extensions: Profile and Sec-flag 11 draft-wang-core-profile-secflag-options-02 13 Abstract 15 This memo adds two Options for the Constrained Application Protocol 16 (CoAP): Profile and Sec-flag. The Profile Option is indicating the 17 identification of an application using CoAP. The Sec-flag Option 18 complements the security considerations of CoAP. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 15, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Profile Option Extension . . . . . . . . . . . . . . . . . 3 70 2.2. Sec-flag Option Extension . . . . . . . . . . . . . . . . 4 71 3. Profile Option . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Profile Option Definition . . . . . . . . . . . . . . . . 5 73 3.1.1. Option Value Length . . . . . . . . . . . . . . . . . 5 74 3.2. Using the Profile Option . . . . . . . . . . . . . . . . . 6 75 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4. Sec-flag Option . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.1. Security Negotiation . . . . . . . . . . . . . . . . . . . 7 78 4.2. Using the Sec-flag Option in data transport . . . . . . . 9 79 4.3. Sec-flag Option Definition . . . . . . . . . . . . . . . . 10 80 4.4. System Overview . . . . . . . . . . . . . . . . . . . . . 10 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 11 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 CoAP is a specialized web transfer protocol for machine-to-machine 91 applications such as smart energy and building automation using with 92 constrained nodes and networks. This memo adds two new options for 93 CoAP: Profile and Sec-flag. 95 The main purpose of the Profile Option is indicating the 96 identification of an application using CoAP, by reading this option 97 some intermediaries (e.g. proxy) and transport networks could 98 distinguish different applications and do some differentiated 99 processing. 101 The Sec-flag Option complements the security considerations, enabling 102 NoSec pattern in a segment of the communication path between the 103 client and server, by taking care of establishing and maintaining 104 lower layer security instead of DTLS in these intermediate networks. 106 1.1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 2. Motivations 114 CoAP is a light-weight web protocol and can be used in constrained 115 devices, fulfilling machine-to-machine requirements. Because of its 116 features, more and more M2M applications MAY adopt CoAP. 118 2.1. Profile Option Extension 120 CoAP applications SHOULD use an operator's network as the transport 121 bearer. Different machine-to-machine applications MAY have different 122 Quality of Service (QoS) requirements in terms of required bit rates 123 as well as acceptable packet delays and packet loss rates. When 124 application data is transmitted through the transport network, the 125 network MAY need to identify different machine-to-machine services to 126 do some differentiated processing, applying different control 127 policies with subscriptions. Before applying control policies to 128 applications, transport networks SHOULD identify them and distinguish 129 each one from another referring to application identification, and 130 then networks MAY apply different policies to different applications. 131 Some intermediaries (e.g.CoAP proxy) MAY also would like to 132 distinguish different applications and do some differentiated 133 processing such as caching and forwarding application data in 134 different priorities. 136 This memo describes the extensions to CoAP and is to provide 137 expanding proposal(s) to fulfill the motivations and requirements, 138 defining an additional Option for the Constrained Application 139 Protocol (CoAP): Profile. The Profile Option is defined as the 140 identification of CoAP applications. When CoAP messages are 141 transmitted through the transport network, network entities MAY use 142 some technologies to read the Option Value to identify the 143 application, and then apply control policies with the subscription of 144 application owner. 146 2.2. Sec-flag Option Extension 148 The transmission path between the client and server MAY consist of 149 some segments: Network domain based on existing standards 3GPP, 150 TISPAN, IETF, etc., and M2M Device and Gateway Domain based on 151 existing standards and technologies like DLMS, CEN, CENELEC,PLT, 152 Zigbee, M-BUS, KNX, etc. The application data MAY be transmitted 153 through different networks between the client and server. 155 The basic CoAP protocol defines the DTLS binding. DTLS would add a 156 per-datagram overhead and some initialization vectors. For some 157 constrained networks and nodes, this is really expensive. And 158 intermediate network domain MAY have some independent and reliable 159 security standards (e.g. ZigBee standard). In some cases, CoAP 160 could use these security standards instead of DTLS to avoid DTLS 161 overhead in some intermediate networks.In these network domains DTLS 162 may be disabled but be retained in other domains. 164 As an example, the ZigBee standard for sensor networks defines a 165 security architecture based on an online trust center and uses CCM* 166 model to secure applications. This standard can fulfill the security 167 requirements of CoAP. That is to say, CoAP applications could be 168 secured by lower layer security, so in this network DTLS could be 169 disabled to avoid DTLS datagram overhead. We just mark a security 170 flag to indicate that CoAP data is secured by lower layer instead in 171 this network domain and the overhead would be much less. And in the 172 Transport Network domain we still establish DTLS security. Thus we 173 MAY enable two different security patterns described in 174 [I-D.ietf-core-coap] in different segments between the client and 175 server. 177 The Sec-flag Option can be used to indicate the security information 178 and ensure the integrality of the security mechanism. 180 3. Profile Option 181 3.1. Profile Option Definition 183 +-----+----------+--------+-------------+---------+---------+ 184 | No. | C/E | Name | Format | Length | Default | 185 +-----+----------+--------+-------------+---------+---------+ 186 | 2n | Elective |Profile |(see below) | 4B | (none) | 187 +-----+----------+--------+-------------+---------+---------+ 189 The Profile Option indicates the identification of CoAP applications. 190 Transport network entities MAY use some technologies to read the 191 Option Value and then apply corresponding treatment. 193 This option is "elective" and the Option Number is even. It MUST NOT 194 occur more than once. 196 The detailed definitions and encoding SHOULD refer to the description 197 of Option Format in [I-D.ietf-core-coap]. It is RECOMMENDED that the 198 Option Value consists of Enterprise Number, Application ID and 199 Priority. 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Enterprise Number | Application ID |Pri| 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 1: Option Value Format 207 As shown in Figure 1, Enterprise Number is the register number of 208 application owners (e.g. traffic management agencies) in network 209 operators. Application ID is the identification of the owner's 210 application which subscribes transport and communication services 211 from operators. Priority (Pri) indicates the priority of application 212 data, data of the same application MAY has different priority (For 213 some cost reasons, application owners MAY subscribe low priority for 214 some application data). 216 The SDNV[RFC5050] encoding can be used. 218 We can distinguish different applications with a combination of 219 Enterprise Number, Application ID and Priority. 221 3.1.1. Option Value Length 223 In actual usages, the number of CoAP application owners MAY be out of 224 length range indicated by 2 bytes, the default length cannot fulfill 225 requirements. Hence, we can define another Option Value Length: 226 5bytes. 228 In the initialization phase of CoAP message, the Option Value Length 229 SHOULD be determined. 231 3.2. Using the Profile Option 233 The semantics of Option Value are defined by prior agreement between 234 the application owners and network operators. Some encryption 235 algorithms MAY be used. Network entities MAY also apply some 236 validation policies when reading the Option Value. 238 CoAP application owners MAY realize functions through a M2M 239 communication for some purposes (e.g. Meter readings) at their 240 customer's premises. The Profile Option can be contained in the 241 application message to indicate the identity. 243 When CoAP messages across transport network, network entities MAY use 244 some technologies such as Deep Packet Inspection (DPI) to read the 245 Profile Option Value and report it to policy control decision 246 function entities. And then policy control decision function 247 entities determine the policies applied to CoAP data as well as 248 establishing dedicated bearers. 250 3.3. Example 252 In some M2M environments, the nodes access to Internet through 3GPP 253 network. 255 This example (Figure 2) shows that mobile network is the bearer 256 between two M2M end-points. These end-points MAY belong to an 257 electric power company and this M2M application is a meter reading 258 service. The profile option value of this application is 0x12111111. 260 +------+ CoAP-REQ +----------+ CoAP-REQ +------+ 261 | | --------> | MOBILE | -------> | | 262 | A | | | | B | 263 | | <-------- | NETWORK | <------- | | 264 +------+ CoAP-RES +----------+ CoAP-RES +------+ 266 Figure 2 An example 268 The message flow is shown in Figure 3. At first the requester 269 (server) sends a request which MAY be a device trigger that makes end 270 devices return electricity records. The number of end devices is 271 numerous and this triggering MAY happen in a preset period of time. 272 All devices return their records at the approximately same time, and 273 the data transmission volume is huge. Hence it is expected that the 274 network SHOULD offer QoS guarantee (such as high bandwidth and 275 throughput) for the M2M application. 277 The requester SHOULD initial the Profile Option when sending a 278 request. Network entities can read the Option Value and know that 279 the application is a meter reading service belonging to a certain 280 electricity company. And then specialized policies MUST be applied. 281 The Profile option value MUST be echoed in the messages from 282 recipients. 284 When the M2M application data comes into the network, network 285 entities MUST provide corresponding policy control with subscriptions 286 and MAY also establish dedicated bearers assign dedicated network 287 resources to ensure the quality of transport and communication if 288 necessary. 290 Requester Recipient 291 | | 292 | | 293 +-------->| Header: GET (T=CON, Code=1, MID=0x7d38) 294 | GET | Token: 0x53 295 | | Profile:0x12111111 296 | | Uri-Path: "electricity" 297 | | 298 | | 299 |<--------+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38) 300 | 2.05 | Token: 0x53 301 | | Profile:0x12111111 302 | | Payload: "25" 303 | | 304 | | 306 Figure 3 Profile Option in CoAP messages 308 4. Sec-flag Option 310 The Sec-flag Option complements the security considerations, enabling 311 NoSec pattern in one or more segments of the communication path 312 between the client and server. 314 4.1. Security Negotiation 316 Before establishing a security session between endpoints, the 317 negotiation SHOULD be made. As shown in Figure 4, the basic model 318 includes three actors: a client, a proxy and a server. 320 Client Proxy Server 321 | | | 322 | Hello | | 323 +---------------------->| | 324 | | | 325 | Set the Sec-flag Option | 326 | | | 327 | | Hello | 328 | +---------------------->| 329 | | | 330 | | verify 331 | | | 332 | | Hello-verify | 333 | |<----------------------+ 334 | | | 335 | Hello-verify | | 336 |<----------------------+ | 337 | | | 338 | | | 340 Figure 4 Basic model 342 (1) Lower security can secure CoAP application data 344 At first, the client sends to the server a hello message in which the 345 Sec-flag Option with an empty value is included. The proxy is 346 requested to forward the request or serve it, and return the 347 response. If the network domain between the client and proxy could 348 guarantee the lower layer security, the proxy SHOULD set the Sec-flag 349 Option with a valid value and transfer the hello message to the 350 server. 352 When the server receives the message, it MUST respond with a server 353 hello-verify message. A response with the same valid option value as 354 the value set in the proxy SHOULD be returned only if the server 355 trusts the lower layer security between the client and proxy. If the 356 server accepts the lower layer security, DTLS would be disabled 357 between the client and proxy and then the proxy SHOULD make a DTLS 358 handshake with the server to make up a DTLS security session. 359 Otherwise, the DTLS handshake SHOULD be made between the client and 360 server, that would be introduced in the following. 362 (2) Lower security cannot secure CoAP application data 364 When the server receives the Hello message, if the server does not 365 trust the lower layer security between the client and proxy, the 366 server would respond a hello-verify message containing an empty 367 Security option and an error code. Then the client would send DTLS 368 handshake messages to the server and establish DTLS between the 369 client and the server. 371 (3) There is no lower security between the client and M2M Gateway 373 Client Proxy 374 | | 375 | Hello | 376 +----------------------->| 377 | | 378 | | 379 | | 380 | | 381 | | 382 | | 383 | | 384 | Error Message | 385 |<-----------------------+ 386 | | 387 | | 389 Figure 5 There is no lower security in the Device and Gateway Domain 391 If the network domain between the client and proxy could not 392 guarantee lower layer security, the proxy SHOULD return an 393 appropriate error response code with an empty Security Option as 394 shown in Figure 5. Then the client would send DTLS handshake 395 messages to the server and establish DTLS between the client and the 396 server. 398 In all the situations, the client and the proxy also need initialize 399 lower security mechanism, which MAY happen either before the Security 400 Option negotiation or after it. 402 4.2. Using the Sec-flag Option in data transport 404 When the security negotiation is completed, a security session is 405 established between the client and server. 407 The Sec-flag Option MUST be included in messages sent by the client 408 and the value SHOULD be empty. When the proxy receives the message, 409 it MUST set the Sec-flag Option with a valid value and transfer the 410 message to the server. The Sec-flag Option indicates that the 411 message comes from a reliable network domain and the server could 412 trust it. And then the server would respond the request. The same 413 Sec-flag Option SHOULD be echoed in the response. When the response 414 comes to the proxy, the proxy reads the option and knows that the 415 message SHOULD be secured by lower layer security. 417 4.3. Sec-flag Option Definition 419 +-----+----------+--------+-------------+---------+---------+ 420 | No. | C/E | Name | Format | Length | Default | 421 +-----+----------+--------+-------------+---------+---------+ 422 | 2n+1| Critical |Sec-flag|(see below) | 1B | (empty) | 423 +-----+----------+--------+-------------+---------+---------+ 425 The Sec-flag Option is used for indicating the lower layer security. 427 This option is "critical" and the Option Number is odd. 429 The detailed definitions and encoding SHOULD refer to the description 430 of Option Format in [I-D.ietf-core-coap]. The value is made up of 431 security indication. 433 The SDNV[RFC5050] encoding can be used. 435 4.4. System Overview 437 +--------+ +---------+ +--------+ 438 | | | | | | 439 | | | | | | 440 | | +---------+ | M2M | +---------+ | | 441 | CLIENT |--->| ZIGBEE |--->| GATEWAY |--->| 3GPP |--->| SERVER | 442 | |<---| NETWORK |<---| |<---| NETWORK |<---| | 443 | | +---------+ | | +---------+ | | 444 | | | | | | 445 | | | | | | 446 +--------+ +---------+ +--------+ 448 Figure 6 System overview of a usage scenario 450 As shown in Figure 6, the nodes access to Internet through 3GPP 451 network. DTLS is enabled between M2M Gateway and application server, 452 and in Zigbee network DTLS is disabled and lower layer security 453 secures CoAP applications. M2M Gateway, working as a "marker", sets 454 the Sec-flag option to show that the data from Zigbee network domain 455 is secured and reliable in the uplink and indicate that the data need 456 low layer security and DTLS SHOULD be disabled in the Zigbee network 457 domain in the downlink. As the intermediate gateway, M2M Gateway 458 needs to transfer the data to each network and adapt the security 459 standard to the other one. M2M Gateway also needs to check the 460 message. When a message from the end devices is received, the 461 gateway checks whether the Sec-flag option is set by the end devices 462 illegally (the default value SHOULD be empty). If the Sec-flag 463 option is not empty, the gateway SHOULD drop it, else the gateway 464 SHOULD set the valid value and transfer the message. 466 5. Security Considerations 468 To be defined. 470 6. IANA Considerations 472 The following entries are added to the CoAP Option Numbers registry: 474 +---------+----------+-------------+ 475 | Number | Name | Reference | 476 +---------+----------+-------------+ 477 | 2n | Profile | RFC XXXX | 478 +---------+----------+-------------+ 479 | 2n+1 | Sec-flag | RFC XXXX | 480 +---------+----------+-------------+ 482 7. References 484 7.1. Normative Reference 486 [I-D.ietf-core-coap] 487 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 488 "Constrained Application Protocol (CoAP)", 489 draft-ietf-core-coap-12 (work in progress), October 2012. 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 495 Specification", RFC 5050, November 2007. 497 7.2. Informative References 499 [I-D.fossati-core-publish-monitor-options] 500 Fossati, T., Giacomin, P., and S. Loreto, "Publish and 501 Monitor Options for CoAP", 502 draft-fossati-core-publish-monitor-options-01 (work in 503 progress), March 2012. 505 Authors' Addresses 507 Lei Wang 508 Beijing University of Posts and Telecommunications 509 Xitucheng road 10 510 Haidian District, Beijing 100876 511 P. R. China 513 Email: wleiblue@163.com 515 Wendong Wang 516 Beijing University of Posts and Telecommunications 517 Xitucheng road 10 518 Haidian District, Beijing 100876 519 P. R. China 521 Email: wdwang@bupt.edu.cn 523 Lei Zhu 524 Huawei Technologies 525 Huawei Building, Q20 No.156 Beiqing Rd.Z-park 526 Haidian District, Beijing 100095 527 P. R. China 529 Email: lei.zhu@huawei.com 531 Fang Yu 532 Huawei Technologies 533 Huawei Building, Q20 No.156 Beiqing Rd.Z-park 534 Haidian District, Beijing 100095 535 P. R. China 537 Email: grace.yufang@huawei.com