idnits 2.17.1 draft-fossati-core-fp-link-format-attribute-00.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 date (July 9, 2012) is 4309 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-10 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-13 ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-18 == Outdated reference: A later version (-05) exists of draft-shelby-core-resource-directory-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Fossati 3 Internet-Draft KoanLogic 4 Intended status: Standards Track S. Loreto 5 Expires: January 10, 2013 Ericsson 6 July 9, 2012 8 Resource Discovery through Proxies 9 draft-fossati-core-fp-link-format-attribute-00 11 Abstract 13 The aim of this draft is to open a discussion on how to make it 14 possible to advertise the fact that a given resource hosted by a 15 server can only be reached through a specific CoAP Proxy. 17 This memo proposes the definition of the "fp" (forward proxy) CoAP 18 link format attribute, that can be used to inform CoAP endpoints that 19 a given resource can be reached by passing through the advertising 20 Proxy. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 10, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 58 2. Proxied Discovery Scenario . . . . . . . . . . . . . . . . . . 3 59 3. The fp Link Format Attribute . . . . . . . . . . . . . . . . . 4 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. fp Attribute . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 The discovery mechanism described in [I-D.ietf-core-link-format] 71 assumes cheap and pervasive multicast. However as discussed in 72 [I-D.shelby-core-resource-directory] direct discovery of resources is 73 not always practical due to limitations in the underlying radio link 74 (see Section 1 of [I-D.ietf-6lowpan-nd]), the absence of a multicast 75 routing protocol to bridge through different links, sleeping nodes, 76 disperse networks. 78 The Resource Directory (RD) provides a first solution hosting 79 descriptions of resources held on other servers and allowing lookups 80 to be performed for those resources. The current solution however 81 does not address the scenario where the URI (of the resource of 82 interest) is associated to a CoAP origin server that can only be 83 accessed through a CoAP proxies either for topological and/or 84 security reasons or because it is a sleepy origin server. 86 Given their topological role, CoAP Proxies (Section 5.7 of 87 [I-D.ietf-core-coap]) can be used effectively to address the above 88 mentioned scenarios. However, in order to achieve this capability, 89 the fact that a given resource is made available through a proxy must 90 be made explicit to consuming endpoints, so that they can use the 91 Proxy-Uri Option to dereference the final target. 93 This memo defines the "fp" (forward proxy) CoAP link format 94 attribute, that can be used to inform CoAP endpoints that a given 95 resource can be reached by passing through the advertising Proxy. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Proxied Discovery Scenario 105 Consider the scenario depicted in Figure 1. Two separate CoAP links 106 are proxied by P. Node A hosts resource /res of type "x", and P knows 107 it -- either through explicit or implicit mechanism (e.g. previous 108 discovery on the local link, or a co-located RD, etc.) 109 | | 110 ;rt="x" (A)---+ | 111 | | 112 +---(P)---+ 113 | | 114 | +---(B) 115 | | 117 Figure 1 119 We would like to allow B to discover that A hosts a resource with 120 type "x" even if A can't be directly reached by B. 122 P may in principle let this information filter from one link to the 123 other, but given the mechanisms currently defined for the discovery 124 via /.well-known/core (Section 2.1 of [I-D.ietf-core-link-format]), 125 there is no way for a consuming node to ascertain that an advertised 126 link is to be accessed through a given forward Proxy or by a direct 127 route. 129 We may choose to use the anchor parameter in the link and define a 130 new relation name to express the "proxied by" relation, but this may 131 actually have zero chance to succeed because of the freedom left to a 132 consuming node to actually ignore anchored links (Section 2.3 of 133 [I-D.ietf-core-link-format]). 135 3. The fp Link Format Attribute 137 The proposed solution, instead, envisages a new link format 138 attribute, "fp" that is added by the Proxy to the original set of 139 attributes of the linked resource to inform the requesting endpoint 140 that the advertised (absolute) URI must be requested to the 141 advertising Proxy using the Proxy-URI Option, as illustrated in 142 Figure 2. The "fp" link format attribute MAY be set to the Proxy IP 143 address. 145 When advertised on a link different from the one on which it resides, 146 the original resource link SHALL be transformed by the Proxy into an 147 absolute URI that can be used as-is in a Proxy-Uri Option by the 148 requesting node. 150 P B 151 | | 152 |<-----' Uri-Path: .well-known 153 | GET | Uri-Path: core 154 | | Uri-Query: rt=x 155 | | 156 `----->| Content-Type: link-format 157 | 2.05 | payload: ;rt="x";fp="proxy IP address" 159 Figure 2 161 Note that in case the "fp" attribute is present, the URI-Reference in 162 the link-value [RFC5988] MUST always be a URI and not a relative-ref 163 [RFC3986]. 165 The forwarding path to /res is now set up, and B can reach it through 166 P using the Proxy-Uri Options as follows: 168 A P B 169 | | | 170 | |<-----' Proxy-Uri: coap://A/res 171 | | GET | 172 |<-----' | Uri-Path: res 173 | GET | | 174 | | | 175 `----->| | 176 | 2.05 | | 177 | `----->| 178 | | 2.05 | 180 4. IANA Considerations 182 4.1. fp Attribute 184 This section defines a new Web Linking [RFC5988] attribute for use 185 with [I-D.ietf-core-link-format]. The "fp" (forward proxy) CoAP link 186 format attribute, that can be used by Proxy nodes to inform CoAP 187 endpoints that a given resource can be reached by passing through the 188 advertising Proxy. 190 5. Security Considerations 192 The mechanism specified in this document shares the same security 193 concerns as the discovery process described in 194 [I-D.ietf-core-link-format]. 196 Especially critical to the CoAP network consistency, is the fact that 197 in NoSec mode a malicious attacker could poison the response of a 198 query to the /.well-known/core in order to re-route traffic. 200 6. References 202 6.1. Normative References 204 [I-D.ietf-core-coap] 205 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 206 "Constrained Application Protocol (CoAP)", 207 draft-ietf-core-coap-10 (work in progress), June 2012. 209 [I-D.ietf-core-link-format] 210 Shelby, Z., "CoRE Link Format", 211 draft-ietf-core-link-format-13 (work in progress), 212 May 2012. 214 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 215 Requirement Levels", BCP 14, RFC 2119, March 1997. 217 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 218 Resource Identifier (URI): Generic Syntax", STD 66, 219 RFC 3986, January 2005. 221 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 223 6.2. Informative References 225 [I-D.ietf-6lowpan-nd] 226 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 227 Discovery Optimization for Low Power and Lossy Networks 228 (6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress), 229 October 2011. 231 [I-D.shelby-core-resource-directory] 232 Krco, S. and Z. Shelby, "CoRE Resource Directory", 233 draft-shelby-core-resource-directory-02 (work in 234 progress), October 2011. 236 Authors' Addresses 238 Thomas Fossati 239 KoanLogic 240 Via di Sabbiuno, 11/5 241 Bologna 40100 242 Italy 244 Email: tho@koanlogic.com 246 Salvatore Loreto 247 Ericsson 248 Hirsalantie 11 249 Jorvas 02420 250 Finland 252 Email: salvatore.loreto@ericsson.com