idnits 2.17.1 draft-ietf-core-http-mapping-03.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 : ---------------------------------------------------------------------------- ** There are 18 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2014) is 3697 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '251557' on line 1000 -- Looks like a reference, but probably isn't: '1' on line 1072 -- Looks like a reference, but probably isn't: '2' on line 1075 -- Looks like a reference, but probably isn't: '3' on line 1078 == Unused Reference: 'RFC6570' is defined on line 1046, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-core-block-12 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-10 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-24 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-24 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-24 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-16 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group A. Castellani 3 Internet-Draft University of Padova 4 Intended status: Informational S. Loreto 5 Expires: August 16, 2014 Ericsson 6 A. Rahman 7 InterDigital Communications, LLC 8 T. Fossati 9 Alcatel-Lucent 10 E. Dijk 11 Philips Research 12 February 12, 2014 14 Guidelines for HTTP-CoAP Mapping Implementations 15 draft-ietf-core-http-mapping-03 17 Abstract 19 This draft provides reference information for HTTP-CoAP protocol 20 translation proxy implementors, focusing primarily on the reverse 21 proxy case. It details deployment options, defines a safe method for 22 URI mapping, and provides a set of guidelines and considerations 23 related to protocol translation. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 16, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Cross-Protocol Usage of URIs . . . . . . . . . . . . . . . . 4 62 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. URI Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Default Mapping . . . . . . . . . . . . . . . . . . . . . 6 66 5.2.1. Optional scheme . . . . . . . . . . . . . . . . . . . 7 67 5.2.2. Encoding Caveats . . . . . . . . . . . . . . . . . . 7 68 5.3. URI Mapping Template . . . . . . . . . . . . . . . . . . 7 69 5.3.1. Simple Form . . . . . . . . . . . . . . . . . . . . . 8 70 5.3.2. Enhanced Form . . . . . . . . . . . . . . . . . . . . 10 71 5.4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 72 5.4.1. Examples . . . . . . . . . . . . . . . . . . . . . . 11 73 6. HTTP-CoAP Reverse Proxy . . . . . . . . . . . . . . . . . . . 12 74 6.1. Proxy Placement . . . . . . . . . . . . . . . . . . . . . 13 75 6.2. Response Code Translations . . . . . . . . . . . . . . . 14 76 6.3. Media Type Translations . . . . . . . . . . . . . . . . . 16 77 6.4. Caching and Congestion Control . . . . . . . . . . . . . 17 78 6.5. Cache Refresh via Observe . . . . . . . . . . . . . . . . 18 79 6.6. Use of CoAP Blockwise Transfer . . . . . . . . . . . . . 18 80 6.7. Security Translation . . . . . . . . . . . . . . . . . . 19 81 6.8. Other guidelines . . . . . . . . . . . . . . . . . . . . 19 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 84 8.1. Traffic overflow . . . . . . . . . . . . . . . . . . . . 21 85 8.2. Handling Secured Exchanges . . . . . . . . . . . . . . . 21 86 8.3. URI Mapping . . . . . . . . . . . . . . . . . . . . . . . 22 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 90 10.2. Informative References . . . . . . . . . . . . . . . . . 24 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 94 1. Introduction 95 CoAP [I-D.ietf-core-coap] has been designed with the twofold aim to 96 be an application protocol specialized for constrained environments 97 and to be easily used in REST architectures such as the Web. The 98 latter goal has led to define CoAP to easily interoperate with HTTP 99 [RFC2616] through an intermediary proxy which performs cross-protocol 100 conversion. 102 Section 10 of [I-D.ietf-core-coap] describes the fundamentals of the 103 CoAP-to-HTTP and the HTTP-to-CoAP cross-protocol mapping process. 104 However, implementing such a cross-protocol proxy can be complex, and 105 many details regarding its internal procedures and design choices 106 require further elaboration. Therefore a first goal of this document 107 is to provide more detailed information to proxy designers and 108 implementers, to help implement proxies that correctly inter-work 109 with other CoAP and HTTP client/server implementations that adhere to 110 the HTTP and CoAP specifications. 112 The second goal of this informational document is to define a 113 consistent set of guidelines that a HTTP-to-CoAP proxy implementation 114 MAY adhere to. The main reason of adhering to such guidelines is to 115 reduce variation between proxy implementations, thereby increasing 116 interoperability. (As an example use case, a proxy conforming to 117 these guidelines made by vendor A can be easily replaced by a proxy 118 from vendor B that also conforms to the guidelines.) 120 This draft is organized as follows: 122 o Section 2 describes terminology to identify proxy types, mapping 123 approaches and proxy deployments; 125 o Section 3 discusses how URIs refer to resources independent of 126 access protocols; 128 o Section 4 briefly lists use cases in which HTTP clients need to 129 contact CoAP servers; 131 o Section 5 introduces a default HTTP-to-CoAP URI mapping syntax; 133 o Section 6 analyzes the mapping that allows HTTP clients to contact 134 CoAP servers; 136 o Section 8 discusses possible security impact related to HTTP-CoAP 137 cross-protocol mapping. 139 2. Terminology 141 This document assumes readers are familiar with the terms Reverse 142 Proxy as defined in [I-D.ietf-httpbis-p1-messaging] and Interception 143 Proxy as defined in [RFC3040]. In addition, the following terms are 144 defined: 146 Cross-Protocol Proxy (or Cross Proxy): is a proxy performing a cross- 147 protocol mapping, in the context of this document a HTTP-CoAP (HC) 148 mapping. A Cross-Protocol Proxy can behave as a Forward Proxy, 149 Reverse Proxy or Interception Proxy. Note: In this document we focus 150 on the Reverse Proxy mode of the Cross-Protocol Proxy. 152 Forward Proxy: a message forwarding agent that is selected by the 153 client, usually via local configuration rules, to receive requests 154 for some type(s) of absolute URI and to attempt to satisfy those 155 requests via translation to the protocol indicated by the absolute 156 URI. The user decides (is willing to) use the proxy as the 157 forwarding/dereferencing agent for a predefined subset of the URI 158 space. 160 Reverse Proxy: a receiving agent that acts as a layer above some 161 other server(s) and translates the received requests to the 162 underlying server's protocol. It behaves as an origin (HTTP) server 163 on its connection towards the (HTTP) client and as a (CoAP) client on 164 its connection towards the (CoAP) origin server. The (HTTP) client 165 uses the "origin-form" [I-D.ietf-httpbis-p1-messaging] as a request- 166 target URI. 168 Reverse and Forward proxies are technically very similar, with main 169 differences being that the former appears to a client as an origin 170 server while the latter does not, and that clients may be unaware 171 they are communicating with a proxy. 173 Placement terms: a server-side (SS) proxy is placed in the same 174 network domain as the server; conversely a client-side (CS) proxy is 175 in the same network domain as the client. In any other case than SS 176 or CS, the proxy is said to be External (E). 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in 181 [RFC2119]. 183 3. Cross-Protocol Usage of URIs 185 A Uniform Resource Identifier (URI) provides a simple and extensible 186 method for identifying a resource. It enables uniform identification 187 of resources via a separately defined extensible set of naming 188 schemes [RFC3986]. 190 URIs are formed of at least three components: scheme, authority and 191 path. The scheme often corresponds to the protocol used to access 192 the resource. However, as noted in Section 1.2.2 of [RFC3986] the 193 scheme does not imply that a particular protocol is used to access 194 the resource. So, we can define the same resource to be accessible 195 by different protocols i.e. the resource can have cross-protocol URIs 196 referring to it. 198 HTTP clients typically only support 'http' and 'https' schemes. 199 Therefore, they cannot directly access CoAP servers (which support 200 'coap' and/or 'coaps'). In this situation, communication is enabled 201 by a Cross-Protocol Proxy, as shown in Figure 1, supporting URI 202 mapping features. Such features are discussed in Section 5. 204 4. Use Cases 206 To illustrate in which situations HTTP to CoAP request mapping may be 207 used, three use cases are briefly described. 209 1. Smartphone and home sensor: A smartphone, when at home, can 210 perform 'coap' requests directly to a home sensor via WiFi. When the 211 smartphone is away from home, the same request is done by an 212 authenticated 'https' request over an external IP network to the home 213 router. The home router contains a HTTP-CoAP proxy. 215 2. Legacy building control application without CoAP: A building 216 control application can use HTTP, but not CoAP. It checks the status 217 of sensors or actuators via a HTTP-CoAP proxy. 219 3. Making sensor data available to 3rd parties: For demonstration or 220 public interest purposes, a HTTP-CoAP proxy may be configured to 221 expose the contents of a sensor to the world via the web (HTTP and/or 222 HTTPS). The sensor can only handle secure 'coaps' requests, 223 therefore the proxy is configured to translate any request to a 224 'coaps' secured request. The proxy is furthermore configured to only 225 pass through GET requests. 227 5. URI Mapping 229 Though, in principle, a CoAP URI could be directly used by a HTTP 230 user agent to de-reference a CoAP resource through a HC Proxy, the 231 reality is that all major web browsers and command line tools do not 232 allow making HTTP requests using URIs with a scheme different from 233 "http" or "https". 235 Thus, there is a need for web applications to "pack" a CoAP URI into 236 a HTTP URI so that it can be (non-destructively) transported from the 237 user agent to the HC Proxy. The HC Proxy can then "unpack" the CoAP 238 URI and finally de-reference it via a CoAP request to the target 239 Server. 241 URI Mapping is the process through which the URI of a CoAP resource 242 is transformed in to an HTTP URI so that: 244 o the requesting HTTP user agent can handle it; 246 o the receiving HC Proxy can extract the intended CoAP URI 247 unambiguously. 249 To this end, the remainder of this section will identify: 251 o the default mechanism to map a CoAP URI into a HTTP URI; 253 o the URI template format to express a class of CoAP-HTTP URI 254 mapping functions; 256 o the discovery mechanism based on [RFC6690] through which clients 257 of a HC Proxy can dynamically discover information about the 258 supported URI Mapping Template(s), as well as the base URI where 259 the HC Proxy function is anchored. 261 5.1. Terminology 263 In the remainder, the following terms will be used with a distinctive 264 meaning: 266 Target CoAP URI: 267 URI which refers to the (final) CoAP resource that has to be 268 de-referenced. It conforms to syntax defined in section 6. 269 of [I-D.ietf-core-coap]. Specifically, it has a scheme of 270 "coap" or "coaps". 272 Hosting HTTP URI: 273 URI that conforms to syntax in section 2.7 of 274 [I-D.ietf-httpbis-p1-messaging]. Its authority component 275 refers to an HC Proxy, whereas path (and query) component(s) 276 embed the information used by an HC Proxy to extract the 277 Target CoAP URI. 279 5.2. Default Mapping 281 The default is for the Target CoAP URI to be appended as-is to a base 282 URI provided by the HC Proxy to form the Hosting HTTP URI. 284 For example: given a base URI http://p.example.com/hc and a Target 285 CoAP URI coap://s.example.com/light, the resulting Hosting HTTP URI 286 would be http://p.example.com/hc/coap://s.example.com/light. 288 Provided a correct Target CoAP URI, the Hosting HTTP URI resulting 289 from the default mapping is always syntactically correct. 290 Furthermore, the Target CoAP URI can always be extracted in an 291 unambiguous way from the Hosting HTTP URI. Also worth noting that, 292 using the default mapping, a query component in the target CoAP 293 resource URI is naturally encoded into the query component of the 294 Hosting URI, e.g.: coap://s.example.com/light?dim=5 becomes http:// 295 p.example.com/hc/coap://s.example.com/light?dim=5. 297 There is no default for the base URI. Therefore it is either known 298 in advance, e.g. as a configuration preset, or dynamically discovered 299 using the mechanism described in Section 5.4. 301 The default URI mapping function is RECOMMENDED to be implemented and 302 activated by default in a HC Proxy, unless there are valid reasons, 303 e.g. application specific, to use a different mapping function. 305 5.2.1. Optional scheme 307 When found in a Hosting HTTP URI, the scheme (i.e. "coap" or 308 "coaps"), the scheme component delimiter (":"), and the double slash 309 ("//") preceding the authority MAY be omitted. In such case, a local 310 default - not defined by this document - applies. 312 So, http://p.example.com/hc/s.coap.example.com/foo could either 313 represent the target coap://s.coap.example.com/foo or coaps:// 314 s.coap.example.com/foo depending on application specific presets. 316 5.2.2. Encoding Caveats 318 When the authority of the Target CoAP URI is given as an IPv6address, 319 then the surrounding square brackets MUST be percent-encoded in the 320 Hosting HTTP URI, in order to comply with the syntax defined in 321 Section 3.3. of [RFC3986] for a URI path segment. E.g.: coap:// 322 [2001:db8::1]/light?on becomes http://p.example.com/hc/coap:// 323 %5B2001:db8::1%5D/light?on. 325 Everything else can be safely copied verbatim from the Target CoAP 326 URI to the Hosting HTTP URI. 328 5.3. URI Mapping Template 329 This section defines a format for the URI template used by a HC Proxy 330 to inform its clients about the expected syntax for the Hosting HTTP 331 URI. 333 When instantiated, an URI Mapping Template is always concatenated to 334 a base URI provided by the HC Proxy via discovery (see Section 5.4), 335 or by other means. 337 A simple form (Section 5.3.1) and an enhanced form (Section 5.3.2) 338 are provided to fit different users' requirements. 340 Both forms are expressed as level 2 URI template's to take care of 341 the expansion of values that are allowed to include reserved URI 342 characters. 344 5.3.1. Simple Form 346 The simple form MUST be used for mappings where the Target CoAP URI 347 is going to be copied verbatim at some fixed position into the 348 Hosting HTTP URI. 350 The following template variables MUST be used in mutual exclusion in 351 a template definition: 353 cu = coap-URI ; from [I-D.ietf-core-coap], Section 6.1 354 su = coaps-URI ; from [I-D.ietf-core-coap], Section 6.2 355 tu = cu / su 357 The same considerations done in Section 5.2.1 apply. 359 5.3.1.1. Examples 361 All the following examples (given as a specific URI mapping template, 362 a Target CoAP URI, and the produced Hosting HTTP URI) use http:// 363 p.example.com/hc as the base URI. 365 1. "coap" URI is a query argument of the Hosting HTTP URI: 367 ?coap_target_uri={+cu} 369 coap://s.example.com/light 371 http://p.example.com/hc?coap_target_uri=coap://s.example.com/light 373 2. "coaps" URI is a query argument of the Hosting HTTP URI: 375 ?coaps_target_uri={+su} 377 coaps://s.example.com/light 379 http://p.example.com/hc?coaps_target_uri=coaps://s.example.com/light 381 3. Target CoAP URI as a query argument of the Hosting HTTP URI: 383 ?target_uri={+tu} 385 coap://s.example.com/light 387 http://p.example.com/hc?target_uri=coap://s.example.com/light 389 or 391 coaps://s.example.com/light 393 http://p.example.com/hc?target_uri=coaps://s.example.com/light 395 4. Target CoAP URI in the path component of the Hosting HTTP URI 396 (i.e. the default URI Mapping template): 398 /{+tu} 400 coap://s.example.com/light 402 http://p.example.com/hc/coap://s.example.com/light 404 or 406 coaps://s.example.com/light 408 http://p.example.com/hc/coaps://s.example.com/light 410 5.3.2. Enhanced Form 412 The enhanced form can be used to express more sophisticated mappings, 413 i.e. those that do not fit into the simple form. 415 There MUST be at most one instance of each of the following template 416 variables in a template definition: 418 s = "coap" / "coaps" ; from [I-D.ietf-core-coap], Sections 6.1 and 6.2 419 hp = host [":" port] ; from [RFC3986] Sections 3.2.2 and 3.2.3 420 p = path-abempty ; from [RFC3986] Section 3.3. 421 q = [ "?" query ] ; from [RFC3986] Section 3.4 423 5.3.2.1. Examples 425 All the following examples (given as a specific URI mapping template, 426 a Target CoAP URI, and the produced Hosting HTTP URI) use http:// 427 p.example.com/hc as the base URI. 429 1. Target CoAP URI components in path segments, and optional query 430 in query component: 432 {+s}{+hp}{+p}{+q} 434 coap://s.example.com/light 436 http://p.example.com/hc/coap/s.example.com/light 438 or 440 coap://s.example.com/light?on 442 http://p.example.com/hc/coap/s.example.com/light?on 444 2. Target CoAP URI components split in individual query arguments: 446 ?s={+s}&hp={+hp}&p={+p}&q={+q} 448 coap://s.example.com/light 450 http://p.example.com/hc?s=coap&hp=s.example.com&p=/light&q 452 or 454 coaps://s.example.com/light?on 455 http://p.example.com/hc?s=coaps&hp=s.example.com&p=/light&q=on 457 5.4. Discovery 459 In order to accommodate site specific needs while allowing third 460 parties to discover the proxy function, the HC Proxy SHOULD publish 461 information related to the location and syntax of the HC Proxy 462 function using the CoRE Link Format [RFC6690] interface. 464 To this aim a new Resource Type, "core.hc", is associated with a base 465 URI, and can be used as the value for the "rt" attribute in a query 466 to the /.well-known/core in order to locate the base URI where the HC 467 Proxy function is anchored. 469 Along with it, the new target attribute "hct" MAY be returned in a 470 "core.hc" link to provide the associated URI Mapping Template. The 471 default template given in Section 5.2, i.e. {+tu}, MUST be assumed if 472 no "hct" attribute is found in the returned link. If an "htc" 473 attribute is present in the returned link, then a compliant client 474 MUST use it to create the Hosting HTTP URI. 476 Discovery SHOULD be available on both the HTTP and the CoAP side of 477 the HC proxy, with one important difference: on the CoAP side the 478 link associated to the "core.hc" resource is returned as an absolute- 479 URI referencing the HTTP interface, while on the HTTP interface it is 480 returned as a reference relative to the HC Proxy origin. 482 5.4.1. Examples 484 o The first example exercises the CoAP interface, and assumes that 485 the default template, {+tu}, is used: 487 Req: GET coap://[ff02::1]/.well-known/core?rt=core.hc 489 Res: 2.05 Content 490 ;rt="core.hc" 492 o The second example - also on the CoAP side of the HC Proxy - uses 493 a custom template, i.e. one where the CoAP URI is carried inside 494 the query component, thus the returned link carries the URI 495 template to be used in an explicit "hct" attribute: 497 Req: GET coap://[ff02::1]/.well-known/core?rt=core.hc 499 Res: 2.05 Content 500 ;rt="core.hc";hct="?uri={+tu}" 502 On the HTTP side there exist two alternatives to transport the link 503 information: 505 o one uses the 'application/link-format' content type and returning 506 the link in the response body: 508 Req: GET http://p.example.com/.well-known/core?rt=core.hc 510 Res: 200 OK 511 Content-Type: application/link-format 512 Content-Length: 18 514 ;rt="core.hc" 516 o the other uses the Link header to encode the link information: 518 Req: GET http://p.example.com/.well-known/core?rt=core.hc 520 Res: 200 OK 521 Link: ;rt="core.hc" 523 o An HC Proxy may expose two different base URIs to differentiate 524 between Target CoAP resources in the "coap" and "coaps" scheme: 526 Req: GET http://p.example.com/.well-known/core?rt=core.hc 528 Res: 200 OK 529 Link: ;rt="core.hc";htc="{+cu}" 530 Link: ;rt="core.hc";htc="{+su}" 532 6. HTTP-CoAP Reverse Proxy 533 A HTTP-CoAP Reverse Cross-Protocol Proxy is accessed by web clients 534 only supporting HTTP, and handles their requests by mapping these to 535 CoAP requests, which are forwarded to CoAP servers; and mapping back 536 the received CoAP responses to HTTP. This mechanism is transparent 537 to the client, which may assume that it is communicating with the 538 intended target HTTP server. In other words, the client accesses the 539 proxy as an origin server using the "origin-form" 540 [I-D.ietf-httpbis-p1-messaging] as a Request Target. 542 Normative requirements on the translation of HTTP requests to CoAP 543 and of the CoAP responses back to HTTP responses are defined in 544 Section 10.2 of [I-D.ietf-core-coap]. However, that section only 545 considers the case of a HTTP-CoAP Forward Cross-Protocol Proxy in 546 which a client explicitly indicates it targets a request to a CoAP 547 server, and does not cover all aspects of proxy implementation in 548 detail. The present section provides guidelines and more details for 549 the implementation of a Reverse Cross-Protocol Proxy, which MAY be 550 followed in addition to the normative requirements. 552 Translation of unicast HTTP requests into multicast CoAP requests is 553 currently out of scope since in a reverse proxy scenario a HTTP 554 client typically expects to receive a single response, not multiple. 555 However a Cross-Protocol Proxy MAY include custom application- 556 specific functions to generate a multicast CoAP request based on a 557 unicast HTTP request and aggregate multiple CoAP responses into a 558 single HTTP response. 560 Note that the guidelines in this section also apply to an HTTP-CoAP 561 Intercepting Cross-Protocol Proxy. 563 6.1. Proxy Placement 565 Typically, a Cross-Protocol Proxy is located at the edge of the 566 constrained network. See Figure 1. The arguments supporting server- 567 side (SS) placement are the following: 569 Caching: Efficient caching requires that all request traffic to a 570 CoAP server is handled by the same proxy which receives HTTP 571 requests from multiple source locations. This maximally reduces 572 the load on (constrained) CoAP servers. 574 Multicast: To support CoAPs use of local-multicast functionality 575 available in a constrained network, the Cross-Protocol Proxy 576 requires a network interface directly attached to the constrained 577 network. 579 TCP/UDP: Translation between HTTP and CoAP requires also TCP/UDP 580 translation; TCP may be the preferred way for communicating with 581 the constrained network due to its reliability or due to 582 intermediate gateways configured to block UDP traffic. 584 Arguments against SS placement, in favor of client-side (CS), are: 586 Scalability: A solution where a single SS proxy has to manage 587 numerous open TCP/IP connections to a large number of HTTP clients 588 is not scalable. (Unless multiple SS proxies are employed with a 589 load-balancing mechanism, which adds complexity.) 591 +------+ 592 | | 593 | DNS | 594 | | 595 +------+ Constrained Network 596 -------------------- 597 / \ 598 / /-----\ /-----\ \ 599 / CoAP CoAP \ 600 / server server \ 601 || \-----/ \-----/ || 602 +------+ HTTP Request +----------+ || 603 |HTTP |------------------------>| HTTP-CoAP| Req /-----\ || 604 |Client| | Cross- |------->| CoAP || 605 | |<------------------------| Proxy |<-------|server || 606 +------+ HTTP Response +----------+ Resp \-----/ || 607 || || 608 || /-----\ || 609 || CoAP || 610 \ server / 611 \ \-----/ / 612 \ /-----\ / 613 \ CoAP / 614 \ server / 615 \ \-----/ / 616 ---------------- 618 Figure 1: Reverse Cross-Protocol Proxy Deployment Scenario 620 6.2. Response Code Translations 622 Table 1 defines all possible CoAP responses along with the HTTP 623 response to which each CoAP response SHOULD be translated. This 624 table complies with the Section 10.2 requirements of 625 [I-D.ietf-core-coap] and is intended to cover all possible cases. 626 Multiple appearances of a HTTP status code in the second column 627 indicates multiple equivalent HTTP responses are possible, depending 628 on the conditions cited in the Notes (third column). 630 +----------------------------+----------------------------+---------+ 631 | CoAP Response Code | HTTP Status Code | Notes | 632 +----------------------------+----------------------------+---------+ 633 | 2.01 Created | 201 Created | 1 | 634 | 2.02 Deleted | 200 OK | 2 | 635 | | 204 No Content | 2 | 636 | 2.03 Valid | 304 Not Modified | 3 | 637 | | 200 OK | 4 | 638 | 2.04 Changed | 200 OK | 2 | 639 | | 204 No Content | 2 | 640 | 2.05 Content | 200 OK | | 641 | 4.00 Bad Request | 400 Bad Request | | 642 | 4.01 Unauthorized | 400 Bad Request | 5 | 643 | 4.02 Bad Option | 400 Bad Request | 6 | 644 | 4.03 Forbidden | 403 Forbidden | | 645 | 4.04 Not Found | 404 Not Found | | 646 | 4.05 Method Not Allowed | 400 Bad Request | 7 | 647 | 4.06 Not Acceptable | 406 Not Acceptable | | 648 | 4.12 Precondition Failed | 412 Precondition Failed | | 649 | 4.13 Request Entity Too | 413 Request Repr. Too | | 650 | Large | Large | | 651 | 4.15 Unsupported Media | 415 Unsupported Media Type | | 652 | Type | | | 653 | 5.00 Internal Server Error | 500 Internal Server Error | | 654 | 5.01 Not Implemented | 501 Not Implemented | | 655 | 5.02 Bad Gateway | 502 Bad Gateway | | 656 | 5.03 Service Unavailable | 503 Service Unavailable | 8 | 657 | 5.04 Gateway Timeout | 504 Gateway Timeout | | 658 | 5.05 Proxying Not | 502 Bad Gateway | 9 | 659 | Supported | | | 660 +----------------------------+----------------------------+---------+ 662 Table 1: HTTP-CoAP Response Mapping 664 Notes: 666 1. A CoAP server may return an arbitrary format payload along with 667 this response. This payload SHOULD be returned as entity in the 668 HTTP 201 response. Section 7.3.2 of 669 [I-D.ietf-httpbis-p2-semantics] does not put any requirement on 670 the format of the payload. (In the past, [RFC2616] did.) 672 2. The HTTP code is 200 or 204 respectively for the case that a CoAP 673 server returns a payload or not. [I-D.ietf-httpbis-p2-semantics] 674 Section 5.3 requires code 200 in case a representation of the 675 action result is returned for DELETE, POST and PUT and code 204 676 if not. Hence, a proxy SHOULD transfer any CoAP payload 677 contained in a 2.02 response to the HTTP client in a 200 OK 678 response. 680 3. A CoAP 2.03 (Valid) response only (1) confirms that the request 681 ETag is valid and (2) provides a new Max-Age value. HTTP 304 682 (Not Modified) also updates some header fields of a stored 683 response. A non-caching proxy may not have enough information to 684 fill in the required values in the HTTP 304 (Not Modified) 685 response, so it may not be advisable for a non-caching proxy to 686 provoke the 2.03 (Valid) response by forwarding an ETag. A 687 caching proxy will fill the information out of the cache. 689 4. A 200 response to a CoAP 2.03 occurs only when the proxy is 690 caching and translated a HTTP request (without validation 691 request) to a CoAP request that includes validation, for 692 efficiency. The proxy receiving 2.03 updates the freshness of 693 the cached representation and returns the entire representation 694 to the HTTP client. 696 5. The HTTP code 401 Unauthorized MUST NOT be used, as long as in 697 CoAP there is no equivalent defined of the required WWW- 698 Authenticate header (Section 3.1 of [I-D.ietf-httpbis-p7-auth]). 700 6. In some cases a proxy receiving 4.02 may retry the request with 701 less CoAP Options in the hope that the server will understand the 702 newly formulated request. For example, if the proxy tried using 703 a Block Option which was not recognized by the CoAP server it may 704 retry without that Block Option. 706 7. The HTTP code "405 Method Not Allowed" MUST NOT be used since 707 CoAP does not provide enough information to determine a value for 708 the required "Allow" response-header field. 710 8. The value of the HTTP "Retry-After" response-header field is 711 taken from the value of the CoAP Max-Age Option, if present. 713 9. This CoAP response can only happen if the proxy itself is 714 configured to use a CoAP Forward Proxy to execute some, or all, 715 of its CoAP requests. 717 6.3. Media Type Translations 719 A Cross-Protocol Proxy translates a media type string, carried in a 720 HTTP Content-Type header in a request, to a CoAP Content-Format 721 Option with the equivalent numeric value. The media types supported 722 by CoAP are defined in the CoAP Content-Format Registry. Any HTTP 723 request with a Content-Type for which the proxy does not know an 724 equivalent CoAP Content-Format number, MUST lead to HTTP response 415 725 (Unsupported Media Type). 727 Also, a CoAP Content-Format value in a response is translated back to 728 the equivalent HTTP Content-Type. If a proxy receives a CoAP 729 Content-Format value that it does not recognize (e.g. because the 730 value is IANA-registered after the proxy software was deployed), and 731 is unable to look up the equivalent HTTP Content-Type on the fly, the 732 proxy SHOULD return an HTTP entity (payload) without Content-Type 733 header (complying to Section 3.1.1.5 of 734 [I-D.ietf-httpbis-p2-semantics]). 736 6.4. Caching and Congestion Control 738 A Cross-Protocol Proxy SHOULD limit the number of requests to CoAP 739 servers by responding, where applicable, with a cached representation 740 of the resource. 742 Duplicate idempotent pending requests by a Cross-Protocol Proxy to 743 the same CoAP resource SHOULD in general be avoided, by duplexing the 744 response to the requesting HTTP clients without duplicating the CoAP 745 request. 747 If the HTTP client times out and drops the HTTP session to the Cross- 748 Protocol Proxy (closing the TCP connection) after the HTTP request 749 was made, a Cross-Protocol Proxy SHOULD wait for the associated CoAP 750 response and cache it if possible. Further requests to the Cross- 751 Protocol Proxy for the same resource can use the result present in 752 cache, or, if a response has still to come, the HTTP requests will 753 wait on the open CoAP session. 755 According to [I-D.ietf-core-coap], a proxy MUST limit the number of 756 outstanding interactions to a given CoAP server to NSTART. To limit 757 the amount of aggregate traffic to a constrained network, the Cross- 758 Protocol Proxy SHOULD also pose a limit to the number of concurrent 759 CoAP requests pending on the same constrained network; further 760 incoming requests MAY either be queued or dropped (returning 503 761 Service Unavailable). This limit and the proxy queueing/dropping 762 behavior SHOULD be configurable. In order to efficiently apply this 763 congestion control, the Cross-Protocol Proxy SHOULD be SS placed. 765 Resources experiencing a high access rate coupled with high 766 volatility MAY be observed [I-D.ietf-core-observe] by the Cross- 767 Protocol Proxy to keep their cached representation fresh while 768 minimizing the number CoAP messages. See Section 6.5. 770 6.5. Cache Refresh via Observe 772 There are cases where using the CoAP observe protocol 773 [I-D.ietf-core-observe] to handle proxy cache refresh is preferable 774 to the validation mechanism based on ETag as defined in 775 [I-D.ietf-core-coap]. Such scenarios include, but are not limited 776 to, sleepy nodes -- with possibly high variance in requests' 777 distribution -- which would greatly benefit from a server driven 778 cache update mechanism. Ideal candidates would also be crowded or 779 very low throughput networks, where reduction of the total number of 780 exchanged messages is an important requirement. 782 This subsection aims at providing a practical evaluation method to 783 decide whether the refresh of a cached resource R is more efficiently 784 handled via ETag validation or by establishing an observation on R. 786 Let T_R be the mean time between two client requests to resource R, 787 let F_R be the freshness lifetime of R representation, and let M_R be 788 the total number of messages exchanged towards resource R. If we 789 assume that the initial cost for establishing the observation is 790 negligible, an observation on R reduces M_R iff T_R < 2*F_R with 791 respect to using ETag validation, that is iff the mean arrival time 792 of requests for resource R is greater than half the refresh rate of 793 R. 795 When using observations M_R is always upper bounded by 2*F_R: in the 796 constrained network no more than 2*F_R messages will be generated 797 towards resource R. 799 6.6. Use of CoAP Blockwise Transfer 801 A Cross-Protocol Proxy SHOULD support CoAP blockwise transfers 802 [I-D.ietf-core-block] to allow transport of large CoAP payloads while 803 avoiding excessive link-layer fragmentation in LLNs, and to cope with 804 small datagram buffers in CoAP end-points as described in 805 [I-D.ietf-core-coap] Section 4.6. 807 A Cross-Protocol Proxy SHOULD attempt to retry a payload-carrying 808 CoAP PUT or POST request with blockwise transfer if the destination 809 CoAP server responded with 4.13 (Request Entity Too Large) to the 810 original request. A Cross-Protocol Proxy SHOULD attempt to use 811 blockwise transfer when sending a CoAP PUT or POST request message 812 that is larger than a value BLOCKWISE_THRESHOLD. The value of 813 BLOCKWISE_THRESHOLD MAY be implementation-specific, for example 814 calculated based on a known or typical UDP datagram buffer size for 815 CoAP end-points, or set to N times the size of a link-layer frame 816 where e.g. N=5, or preset to a known IP MTU value, or set to a known 817 Path MTU value. The value BLOCKWISE_THRESHOLD or parameters from 818 which it is calculated SHOULD be configurable in a proxy 819 implementation. 821 The Cross-Protocol Proxy SHOULD detect CoAP end-points not supporting 822 blockwise transfers by checking for a 4.02 (Bad Option) response 823 returned by an end-point in response to a CoAP request with a Block* 824 Option. This allows the Cross-Protocol Proxy to be more efficient, 825 not attempting repeated blockwise transfers to CoAP servers that do 826 not support it. However if a request payload is too large to be sent 827 as a single CoAP request and blockwise transfer would be unavoidable, 828 the proxy still SHOULD attempt blockwise transfer on such an end- 829 point before returning 413 (Request Entity Too Large) to the HTTP 830 client. 832 For improved latency a cross proxy MAY initiate a blockwise CoAP 833 request triggered by an incoming HTTP request even when the HTTP 834 request message has not yet been fully received, but enough data has 835 been received to send one or more data blocks to a CoAP server 836 already. This is particularly useful on slow client-to-proxy 837 connections. 839 6.7. Security Translation 841 A HC proxy SHOULD implement explicit rules for security context 842 translations. A translation may involve e.g. applying a rule that 843 any "https" request is translated to a "coaps" request, or e.g. 844 applying a rule that a "https" request is translated to an unsecured 845 "coap" request. Another rule could specify the security policy and 846 parameters used for DTLS connections. Such rules will largely depend 847 on the application and network context in which a proxy is applied. 848 To enable widest possible use of a proxy implementation, these rules 849 SHOULD be configurable in a HC proxy. 851 If a policy for access to 'coaps' URIs is configurable in a HC proxy, 852 it is RECOMMENDED that the policy is by default configured to 853 disallow access to any 'coaps' URI by a HTTP client using an 854 unsecured (non-TLS) connection. Naturally, a user MAY reconfigure 855 the policy to allow such access in specific cases. 857 6.8. Other guidelines 859 For long delays of a CoAP server, the HTTP client or any other proxy 860 in between MAY timeout. Further discussion of timeouts in HTTP is 861 available in Section 6.2.4 of [I-D.ietf-httpbis-p1-messaging]. 863 A cross proxy MUST define an internal timeout for each pending CoAP 864 request, because the CoAP server may silently die before completing 865 the request. The timeout value SHOULD be approximately less than or 866 equal to MAX_RTT defined in [I-D.ietf-core-coap]. 868 When the DNS protocol is not used between CoAP nodes in a constrained 869 network, defining valid FQDN (i.e., DNS entries) for constrained CoAP 870 servers, where possible, MAY help HTTP clients to access the 871 resources offered by these servers via a HC proxy. 873 HTTP connection pipelining (section 6.2.2.1 of 874 [I-D.ietf-httpbis-p1-messaging]) MAY be supported by the proxy and is 875 transparent to the CoAP network: the HC cross proxy will sequentially 876 serve the pipelined requests by issuing different CoAP requests. 878 It is expected that the HC function will often be implemented in 879 software on the proxy. Many different software approaches are 880 possible, including using CGI [RFC3875] as an interface between the 881 HTTP layer and the protocol translation engine. 883 7. IANA Considerations 885 This memo includes no request to IANA. 887 8. Security Considerations 889 The security concerns raised in Section 15.7 of [RFC2616] also apply 890 to the cross proxy scenario. In fact, the cross proxy is a trusted 891 (not rarely a transparently trusted) component in the network path. 893 The trustworthiness assumption on the cross proxy cannot be dropped. 894 Even if we had a blind, bi-directional, end-to-end, tunneling 895 facility like the one provided by the CONNECT method in HTTP, and 896 also assuming the existence of a DTLS-TLS transparent mapping, the 897 two tunneled ends should be speaking the same application protocol, 898 which is not the case. Basically, the protocol translation function 899 is a core duty of the cross proxy that can't be removed, and makes it 900 a necessarily trusted, impossible to bypass, component in the 901 communication path. 903 A reverse proxy deployed at the boundary of a constrained network is 904 an easy single point of failure for reducing availability. As such, 905 a special care should be taken in designing, developing and operating 906 it, keeping in mind that, in most cases, it could have fewer 907 limitations than the constrained devices it is serving. 909 The following sub paragraphs categorize and argue about a set of 910 specific security issues related to the translation, caching and 911 forwarding functionality exposed by a cross proxy module. 913 8.1. Traffic overflow 915 Due to the typically constrained nature of CoAP nodes, particular 916 attention SHOULD be posed in the implementation of traffic reduction 917 mechanisms (see Section 6.4), because inefficient implementations can 918 be targeted by unconstrained Internet attackers. Bandwidth or 919 complexity involved in such attacks is very low. 921 An amplification attack to the constrained network may be triggered 922 by a multicast request generated by a single HTTP request mapped to a 923 CoAP multicast resource, as considered in Section TBD of 924 [I-D.ietf-core-coap]. 926 The impact of this amplification technique is higher than an 927 amplification attack carried out by a malicious constrained device 928 (e.g. ICMPv6 flooding, like Packet Too Big, or Parameter Problem on a 929 multicast destination [RFC4732]), since it does not require direct 930 access to the constrained network. 932 The feasibility of this attack, disruptive in terms of CoAP server 933 availability, can be limited by access controlling the exposed HTTP 934 multicast resource, so that only known/authorized users access such 935 URIs. 937 8.2. Handling Secured Exchanges 939 It is possible that the request from the client to the cross proxy is 940 sent over a secured connection. However, there may or may not exist 941 a secure connection mapping to the other protocol. For example, a 942 secure distribution method for multicast traffic is complex and MAY 943 not be implemented (see [I-D.ietf-core-groupcomm]). 945 By default, a cross proxy SHOULD reject any secured client request if 946 there is no configured security policy mapping. This recommendation 947 MAY be relaxed in case the destination network is believed to be 948 secured by other, complementary, means. E.g.: assumed that CoAP 949 nodes are isolated behind a firewall (e.g. as the SS cross proxy 950 deployment shown in Figure 1), the cross proxy may be configured to 951 translate the incoming HTTPS request using plain CoAP (i.e. NoSec 952 mode.) 954 The HC URI mapping MUST NOT map to HTTP (see Section 5) a CoAP 955 resource intended to be accessed only using HTTPS. 957 A secured connection that is terminated at the cross proxy, i.e. the 958 proxy decrypts secured data locally, raises an ambiguity about the 959 cacheability of the requested resource. The cross proxy SHOULD NOT 960 cache any secured content to avoid any leak of secured information. 961 However in some specific scenario, a security/efficiency trade-off 962 could motivate caching secured information; in that case the caching 963 behavior MAY be tuned to some extent on a per-resource basis. 965 8.3. URI Mapping 967 The following risks related to the URI mapping described in Section 5 968 have been identified: 970 DoS attack on the internal network. 971 Default deny any Target CoAP URI whose authority is (or maps to) a 972 multicast address. Then explicitly whitelist multicast resources 973 that are allowed to be de-referenced. 975 Leaking information on the internal network resources and topology. 976 Default deny any Target CoAP URI (especially /.well-known/core is 977 the resource to be protected), and then explicit whitelist 978 resources that are allowed to be seen from outside. 980 Reduced privacy due to the mechanics of the URI mapping. 981 The internal CoAP Target resource is totally transparent from 982 outside: an HC Proxy implementing a HTTPS-only interface makes the 983 Target CoAP URI totally opaque to a passive attacker. 985 9. Acknowledgements 987 An initial version of the table found in Section 6.2 has been 988 provided in revision -05 of [I-D.ietf-core-coap]. Special thanks to 989 Peter van der Stok for countless comments and discussions on this 990 document, that contributed to its current structure and text. 992 Thanks to Carsten Bormann, Zach Shelby, Michele Rossi, Nicola Bui, 993 Michele Zorzi, Klaus Hartke, Cullen Jennings, Kepeng Li, Brian Frank, 994 Peter Saint-Andre, Kerry Lynn, Linyi Tian, Dorothy Gellert, Francesco 995 Corazza for helpful comments and discussions that have shaped the 996 document. 998 The research leading to these results has received funding from the 999 European Community's Seventh Framework Programme [FP7/2007-2013] 1000 under grant agreement n. [251557]. 1002 10. References 1003 10.1. Normative References 1005 [I-D.ietf-core-block] 1006 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1007 draft-ietf-core-block-12 (work in progress), June 2013. 1009 [I-D.ietf-core-coap] 1010 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1011 Application Protocol (CoAP)", draft-ietf-core-coap-18 1012 (work in progress), June 2013. 1014 [I-D.ietf-core-observe] 1015 Hartke, K., "Observing Resources in CoAP", draft-ietf- 1016 core-observe-10 (work in progress), September 2013. 1018 [I-D.ietf-httpbis-p1-messaging] 1019 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1020 (HTTP/1.1): Message Syntax and Routing", draft-ietf- 1021 httpbis-p1-messaging-24 (work in progress), September 1022 2013. 1024 [I-D.ietf-httpbis-p2-semantics] 1025 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1026 (HTTP/1.1): Semantics and Content", draft-ietf- 1027 httpbis-p2-semantics-24 (work in progress), September 1028 2013. 1030 [I-D.ietf-httpbis-p7-auth] 1031 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1032 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-24 1033 (work in progress), September 2013. 1035 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1036 Requirement Levels", BCP 14, RFC 2119, March 1997. 1038 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1039 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1040 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1042 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1043 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1044 3986, January 2005. 1046 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 1047 and D. Orchard, "URI Template", RFC 6570, March 2012. 1049 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1050 Format", RFC 6690, August 2012. 1052 10.2. Informative References 1054 [I-D.ietf-core-groupcomm] 1055 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1056 draft-ietf-core-groupcomm-16 (work in progress), October 1057 2013. 1059 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 1060 Replication and Caching Taxonomy", RFC 3040, January 2001. 1062 [RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface 1063 (CGI) Version 1.1", RFC 3875, October 2004. 1065 [RFC4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of- 1066 Service Considerations", RFC 4732, December 2006. 1068 Appendix A. Change Log 1070 Changes from ietf-02 to ietf-03: 1072 o Closed Ticket #351 [1] "Add security implications of proposed 1073 default HC URI mapping"; 1075 o Closed Ticket #363 [2] "Remove CoAP scheme in default HTTP-CoAP 1076 URI mapping"; 1078 o Closed Ticket #364 [3] "Add discovery of HTTP-CoAP mapping 1079 resource(s)". 1081 Changes from ietf-01 to ietf-02: 1083 o Selection of single default URI mapping proposal as proposed to WG 1084 mailing list 2013-10-09. 1086 Changes from ietf-00 to ietf-01: 1088 o Added URI mapping proposals to Section 4 as per the Email 1089 proposals to WG mailing list from Esko. 1091 Authors' Addresses 1093 Angelo P. Castellani 1094 University of Padova 1095 Via Gradenigo 6/B 1096 Padova 35131 1097 Italy 1099 Email: angelo@castellani.net 1100 Salvatore Loreto 1101 Ericsson 1102 Hirsalantie 11 1103 Jorvas 02420 1104 Finland 1106 Email: salvatore.loreto@ericsson.com 1108 Akbar Rahman 1109 InterDigital Communications, LLC 1110 1000 Sherbrooke Street West 1111 Montreal H3A 3G4 1112 Canada 1114 Phone: +1 514 585 0761 1115 Email: Akbar.Rahman@InterDigital.com 1117 Thomas Fossati 1118 Alcatel-Lucent 1119 3 Ely Road 1120 Milton, Cambridge CB24 6DD 1121 UK 1123 Email: thomas.fossati@alcatel-lucent.com 1125 Esko Dijk 1126 Philips Research 1127 High Tech Campus 34 1128 Eindhoven 5656 AE 1129 The Netherlands 1131 Email: esko.dijk@philips.com