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

Versions: 00

HIP Working Group                                             A. Keranen
Internet-Draft                                              G. Camarillo
Intended status: Experimental                                   Ericsson
Expires: January 7, 2010                                    July 6, 2009


 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE)
  Instance Specification for REsource LOcation And Discovery (RELOAD)
                draft-keranen-hip-reload-instance-00.txt

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 7, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document specifies the HIP BONE instance specification for
   RELOAD.  It provides the details needed to build a RELOAD-based



Keranen & Camarillo      Expires January 7, 2010                [Page 1]

Internet-Draft      HIP BONE Instance Spec for RELOAD          July 2009


   overlay that uses HIP.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Peer ID to ORCHID Transformation  . . . . . . . . . . . . . . . 3
   5.  Mapping between Protocol Primitives and HIP Messages  . . . . . 3
   6.  Routing HIP Messages via the Overlay  . . . . . . . . . . . . . 4
   7.  Packet Formats  . . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . 5
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   11. Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6


































Keranen & Camarillo      Expires January 7, 2010                [Page 2]

Internet-Draft      HIP BONE Instance Spec for RELOAD          July 2009


1.  Introduction

   The HIP BONE (Host Identify Protocol-Based Overlay Networking
   Environment) specification [I-D.ietf-hip-bone] provides a high-level
   framework for building HIP-based [RFC5201] overlays.  The HIP BONE
   framework leaves the specification of the details on how to combine a
   particular peer protocol with HIP to build an overlay up to documents
   referred to as HIP BONE instance specifications.  A HIP BONE instance
   specification needs to define, minimally:

   o  the peer protocol to be used
   o  how to transform the peer IDs used by the peer protocol into the
      ORCHIDs (Overlay Routable Cryptographic Hash Identifiers)
      [RFC4843] that will be used in HIP
   o  which peer protocol primitives trigger HIP messages

   This document addresses all the previous items and provides
   additional details needed to built RELOAD-based HIP BONEs.


2.  Terminology

   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 RFC 2119 [RFC2119].


3.  Peer Protocol

   The peer protocol to be used is RELOAD, which is specified in
   [I-D.ietf-p2psip-base].  When used with RELOAD, HIP takes the role of
   the RELOAD's Forwarding and Link Management Layer (described in
   Section 5.5. of [I-D.ietf-p2psip-base]).  The RELOAD HIP BONE
   instance provides to the applications the RELOAD Messaging API.


4.  Peer ID to ORCHID Transformation

   RELOAD uses 128 bit peer IDs called Node-IDs.  Since HIP uses 128 bit
   ORCHIDs, peer's ORCHID can be used as such as the RELOAD Node-ID.


5.  Mapping between Protocol Primitives and HIP Messages

   The Attach procedure in RELOAD establishes a connection between two
   peers.  This procedure is performed using the AttachReq and AttachAns
   messages.  When HIP is used, the Attach procedure is performed by
   using a HIP base exchange.  That is, peers send HIP I1 messages



Keranen & Camarillo      Expires January 7, 2010                [Page 3]

Internet-Draft      HIP BONE Instance Spec for RELOAD          July 2009


   instead of RELOAD AttachReq messages.

   The RELOAD AttachLite procedure is used for the same purpose as the
   Attach procedure in scenarios with no NATs.  When HIP is used, the
   AttachLite procedure is also performed by using a HIP base exchange.
   That is, peers send HIP I1 messages instead of RELOAD AttachLiteReq
   messages.

   All other RELOAD messages are sent as such between the peers using
   the paths set up by HIP.


6.  Routing HIP Messages via the Overlay

   If a host has no valid locator for the receiver of a new HIP packet,
   and the receiver is part of a RELOAD HIP BONE overlay the host is
   participating in, the host can send the HIP packet to the receiver
   using the overlay routing.

   When sending a HIP packet via the overlay, the host MUST add an empty
   ROUTE_VIA parameter [I-D.ietf-camarillo-hip-via] to the packet with
   the SYMMETRIC flag set and with an OVERLAY_ID parameter (see
   Section 7) containing the identifier of the right overlay network.
   Host consults the RELOAD Topology Plugin for the next hop and sends
   the HIP packet to that host.

   An intermediate host receiving a HIP packet with the OVERLAY_ID
   parameter checks if it is participating in that overlay, and drops
   packets sent to unknown overlays.  If the host is not the final
   destination of the packet (i.e., the HIP header's receiver's HIT does
   not match to any of its HITs), it checks if the packet contains a
   ROUTE_DST parameter.  Such packets are forwarded to the next hop as
   specified in [I-D.ietf-camarillo-hip-via].  Otherwise, the host finds
   the next hop from the RELOAD Topology Plugin and forwards the packet
   there.  The host MUST add the HIT it uses on the HIP association with
   the next hop host to the end of the ROUTE_VIA parameter, if present.

   When the final destination host receives the HIP packet, the host
   processes it as specified in [RFC5201].  If the HIP packet generates
   a response, the response is routed back on the same path using
   ROUTE_DST parameter as specified in [I-D.ietf-camarillo-hip-via].










Keranen & Camarillo      Expires January 7, 2010                [Page 4]

Internet-Draft      HIP BONE Instance Spec for RELOAD          July 2009


7.  Packet Formats

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Identifier                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type        [ TBD by IANA: 980 ]
     Length      4
     Identifier  32 bit identifier for the overlay

               Figure 1: Format of the OVERLAY_ID parameter

   Figure 1 shows the format of a new HIP parameter used for identifying
   the right overlay if a host participates in multiple overlay
   networks.  For RELOAD HIP BONE overlay networks, the identifier is
   calculated as defined in Section 5.3.2 of [I-D.ietf-p2psip-base].


8.  NAT Traversal

   RELOAD relies on the Forwarding and Link Management Layer providing
   NAT traversal capabilities.  Thus, the RELOAD HIP BONE instance
   implementation MUST implement [I-D.ietf-hip-nat-traversal] or some
   other reliable NAT traversal mechanism.

   HIP relay servers are not generally needed with this HIP BONE
   instance since the overlay network can be used for relaying the Base
   Exchange and further HIP signaling can be done directly between the
   peers.


9.  Security Considerations

   TBD.


10.  IANA Considerations

   This section is to be interpreted according to [RFC5226].

   This document updates the IANA Registry for HIP Parameter Types
   [RFC5201] by assigning new HIP Parameter Type value for the new HIP
   Parameter OVERLAY_ID (defined in Section 7).




Keranen & Camarillo      Expires January 7, 2010                [Page 5]

Internet-Draft      HIP BONE Instance Spec for RELOAD          July 2009


11.  Normative References

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

   [RFC4843]  Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
              for Overlay Routable Cryptographic Hash Identifiers
              (ORCHID)", RFC 4843, April 2007.

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", RFC 5201, April 2008.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [I-D.ietf-hip-bone]
              Camarillo, G., Nikander, P., Hautakorpi, J., and A.
              Johnston, "HIP BONE: Host Identity Protocol (HIP) Based
              Overlay Networking  Environment", draft-ietf-hip-bone-01
              (work in progress), March 2009.

   [I-D.ietf-p2psip-base]
              Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
              H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
              Base Protocol", draft-ietf-p2psip-base-02 (work in
              progress), March 2009.

   [I-D.ietf-hip-nat-traversal]
              Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
              Keraenen, "Basic HIP Extensions for Traversal of Network
              Address Translators", draft-ietf-hip-nat-traversal-08
              (work in progress), June 2009.

   [I-D.ietf-camarillo-hip-via]
              Camarillo, G. and A. Keranen, "Host Identity Protocol
              (HIP) Multi-hop Routing Extension",
              draft-ietf-camarillo-hip-via-00 (work in progress),
              July 2009.












Keranen & Camarillo      Expires January 7, 2010                [Page 6]

Internet-Draft      HIP BONE Instance Spec for RELOAD          July 2009


Authors' Addresses

   Ari Keranen
   Ericsson
   Hirsalantie 11
   02420 Jorvas
   Finland

   Email: ari.keranen@ericsson.com


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com

































Keranen & Camarillo      Expires January 7, 2010                [Page 7]


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