[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                               T. Fossati
Internet-Draft                                                 KoanLogic
Intended status: Standards Track                               S. Loreto
Expires: January 10, 2013                                       Ericsson
                                                            July 9, 2012


                   Resource Discovery through Proxies
             draft-fossati-core-fp-link-format-attribute-00

Abstract

   The aim of this draft is to open a discussion on how to make it
   possible to advertise the fact that a given resource hosted by a
   server can only be reached through a specific CoAP Proxy.

   This memo proposes the definition of the "fp" (forward proxy) CoAP
   link format attribute, that can be used to inform CoAP endpoints that
   a given resource can be reached by passing through the advertising
   Proxy.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 10, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Fossati & Loreto        Expires January 10, 2013                [Page 1]


Internet-Draft     Resource Discovery through Proxies          July 2012


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Proxied Discovery Scenario  . . . . . . . . . . . . . . . . . . 3
   3.  The fp Link Format Attribute  . . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  fp Attribute  . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
































Fossati & Loreto        Expires January 10, 2013                [Page 2]


Internet-Draft     Resource Discovery through Proxies          July 2012


1.  Introduction

   The discovery mechanism described in [I-D.ietf-core-link-format]
   assumes cheap and pervasive multicast.  However as discussed in
   [I-D.shelby-core-resource-directory] direct discovery of resources is
   not always practical due to limitations in the underlying radio link
   (see Section 1 of [I-D.ietf-6lowpan-nd]), the absence of a multicast
   routing protocol to bridge through different links, sleeping nodes,
   disperse networks.

   The Resource Directory (RD) provides a first solution hosting
   descriptions of resources held on other servers and allowing lookups
   to be performed for those resources.  The current solution however
   does not address the scenario where the URI (of the resource of
   interest) is associated to a CoAP origin server that can only be
   accessed through a CoAP proxies either for topological and/or
   security reasons or because it is a sleepy origin server.

   Given their topological role, CoAP Proxies (Section 5.7 of
   [I-D.ietf-core-coap]) can be used effectively to address the above
   mentioned scenarios.  However, in order to achieve this capability,
   the fact that a given resource is made available through a proxy must
   be made explicit to consuming endpoints, so that they can use the
   Proxy-Uri Option to dereference the final target.

   This memo defines the "fp" (forward proxy) CoAP link format
   attribute, that can be used to inform CoAP endpoints that a given
   resource can be reached by passing through the advertising Proxy.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Proxied Discovery Scenario

   Consider the scenario depicted in Figure 1.  Two separate CoAP links
   are proxied by P. Node A hosts resource /res of type "x", and P knows
   it -- either through explicit or implicit mechanism (e.g. previous
   discovery on the local link, or a co-located RD, etc.)









Fossati & Loreto        Expires January 10, 2013                [Page 3]


Internet-Draft     Resource Discovery through Proxies          July 2012


                                |         |
            </res>;rt="x" (A)---+         |
                                |         |
                                +---(P)---+
                                |         |
                                |         +---(B)
                                |         |

                                 Figure 1

   We would like to allow B to discover that A hosts a resource with
   type "x" even if A can't be directly reached by B.

   P may in principle let this information filter from one link to the
   other, but given the mechanisms currently defined for the discovery
   via /.well-known/core (Section 2.1 of [I-D.ietf-core-link-format]),
   there is no way for a consuming node to ascertain that an advertised
   link is to be accessed through a given forward Proxy or by a direct
   route.

   We may choose to use the anchor parameter in the link and define a
   new relation name to express the "proxied by" relation, but this may
   actually have zero chance to succeed because of the freedom left to a
   consuming node to actually ignore anchored links (Section 2.3 of
   [I-D.ietf-core-link-format]).


3.  The fp Link Format Attribute

   The proposed solution, instead, envisages a new link format
   attribute, "fp" that is added by the Proxy to the original set of
   attributes of the linked resource to inform the requesting endpoint
   that the advertised (absolute) URI must be requested to the
   advertising Proxy using the Proxy-URI Option, as illustrated in
   Figure 2.  The "fp" link format attribute MAY be set to the Proxy IP
   address.

   When advertised on a link different from the one on which it resides,
   the original resource link SHALL be transformed by the Proxy into an
   absolute URI that can be used as-is in a Proxy-Uri Option by the
   requesting node.










Fossati & Loreto        Expires January 10, 2013                [Page 4]


Internet-Draft     Resource Discovery through Proxies          July 2012


       P      B
       |      |
       |<-----' Uri-Path: .well-known
       |  GET | Uri-Path: core
       |      | Uri-Query: rt=x
       |      |
       `----->| Content-Type: link-format
       | 2.05 | payload: <coap://A/res>;rt="x";fp="proxy IP address"

                                 Figure 2

   Note that in case the "fp" attribute is present, the URI-Reference in
   the link-value [RFC5988] MUST always be a URI and not a relative-ref
   [RFC3986].

   The forwarding path to /res is now set up, and B can reach it through
   P using the Proxy-Uri Options as follows:

                  A      P      B
                  |      |      |
                  |      |<-----' Proxy-Uri: coap://A/res
                  |      |  GET |
                  |<-----'      | Uri-Path: res
                  |  GET |      |
                  |      |      |
                  `----->|      |
                  | 2.05 |      |
                  |      `----->|
                  |      | 2.05 |


4.  IANA Considerations

4.1.  fp Attribute

   This section defines a new Web Linking [RFC5988] attribute for use
   with [I-D.ietf-core-link-format].  The "fp" (forward proxy) CoAP link
   format attribute, that can be used by Proxy nodes to inform CoAP
   endpoints that a given resource can be reached by passing through the
   advertising Proxy.


5.  Security Considerations

   The mechanism specified in this document shares the same security
   concerns as the discovery process described in
   [I-D.ietf-core-link-format].




Fossati & Loreto        Expires January 10, 2013                [Page 5]


Internet-Draft     Resource Discovery through Proxies          July 2012


   Especially critical to the CoAP network consistency, is the fact that
   in NoSec mode a malicious attacker could poison the response of a
   query to the /.well-known/core in order to re-route traffic.


6.  References

6.1.  Normative References

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-10 (work in progress), June 2012.

   [I-D.ietf-core-link-format]
              Shelby, Z., "CoRE Link Format",
              draft-ietf-core-link-format-13 (work in progress),
              May 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, October 2010.

6.2.  Informative References

   [I-D.ietf-6lowpan-nd]
              Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
              Discovery Optimization for Low Power and Lossy Networks
              (6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress),
              October 2011.

   [I-D.shelby-core-resource-directory]
              Krco, S. and Z. Shelby, "CoRE Resource Directory",
              draft-shelby-core-resource-directory-02 (work in
              progress), October 2011.











Fossati & Loreto        Expires January 10, 2013                [Page 6]


Internet-Draft     Resource Discovery through Proxies          July 2012


Authors' Addresses

   Thomas Fossati
   KoanLogic
   Via di Sabbiuno, 11/5
   Bologna  40100
   Italy

   Email: tho@koanlogic.com


   Salvatore Loreto
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: salvatore.loreto@ericsson.com

































Fossati & Loreto        Expires January 10, 2013                [Page 7]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/