GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8004

Internet Engineering Task Force (IETF) J. Laganier Request for Comments: 8004 Luminate Wireless, Inc. Obsoletes: 5204 L. Eggert Category: Standards Track NetApp ISSN: 2070-1721 October 2016

         Host Identity Protocol (HIP) Rendezvous Extension

Abstract

 This document defines a rendezvous extension for the Host Identity
 Protocol (HIP).  The rendezvous extension extends HIP and the HIP
 Registration Extension for initiating communication between HIP nodes
 via HIP rendezvous servers.  Rendezvous servers improve reachability
 and operation when HIP nodes are multihomed or mobile.  This document
 obsoletes RFC 5204.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc8004.

Copyright Notice

 Copyright (c) 2016 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
 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.

Laganier & Eggert Standards Track [Page 1] RFC 8004 HIP Rendezvous Extension October 2016

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
 3.  Overview of Rendezvous Server Operation . . . . . . . . . . .   3
   3.1.  Diagram Notation  . . . . . . . . . . . . . . . . . . . .   5
   3.2.  Rendezvous Client Registration  . . . . . . . . . . . . .   5
   3.3.  Relaying the Base Exchange  . . . . . . . . . . . . . . .   6
 4.  Rendezvous Server Extensions  . . . . . . . . . . . . . . . .   7
   4.1.  RENDEZVOUS Registration Type  . . . . . . . . . . . . . .   7
   4.2.  Parameter Formats and Processing  . . . . . . . . . . . .   7
     4.2.1.  RVS_HMAC Parameter  . . . . . . . . . . . . . . . . .   7
     4.2.2.  FROM Parameter  . . . . . . . . . . . . . . . . . . .   8
     4.2.3.  VIA_RVS Parameter . . . . . . . . . . . . . . . . . .   9
   4.3.  Modified Packets Processing . . . . . . . . . . . . . . .   9
     4.3.1.  Processing Outgoing I1 Packets  . . . . . . . . . . .   9
     4.3.2.  Processing Incoming I1 Packets  . . . . . . . . . . .  10
     4.3.3.  Processing Outgoing R1 Packets  . . . . . . . . . . .  10
     4.3.4.  Processing Incoming R1 Packets  . . . . . . . . . . .  10
 5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
 6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
 7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
   7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
   7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
 Appendix A.  Changes from RFC 5204  . . . . . . . . . . . . . . .  14
 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction

 "The Host Identity Protocol (HIP) Architecture" [HIP-ARCH] introduces
 the rendezvous mechanism to help a HIP node to contact a frequently
 moving HIP node.  The rendezvous mechanism involves a third party,
 the rendezvous server (RVS), which serves as an initial contact point
 ("rendezvous point") for its clients.  The clients of an RVS are HIP
 nodes that use the HIP Registration Extension [RFC8003] to register
 their HIT->IP address mappings with the RVS.  After this
 registration, other HIP nodes can initiate a base exchange using the
 IP address of the RVS instead of the current IP address of the node
 they attempt to contact.  Essentially, the clients of an RVS become
 reachable at the RVS's IP address.  Peers can initiate a HIP base
 exchange with the IP address of the RVS, which will relay this
 initial communication such that the base exchange may successfully
 complete.

Laganier & Eggert Standards Track [Page 2] RFC 8004 HIP Rendezvous Extension October 2016

2. Terminology

 This section defines terms used throughout the remainder of this
 specification.
 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].
 In addition to the terminology defined in the HIP specification
 [RFC7401] and the HIP Registration Extension [RFC8003], this document
 defines and uses the following terms:
 Rendezvous Service
    A HIP service provided by an RVS to its rendezvous clients.  The
    RVS offers to relay some of the arriving base exchange packets
    between the Initiator and Responder.
 Rendezvous Server (RVS)
    A HIP registrar providing rendezvous service.
 Rendezvous Client
    A HIP requester that has registered for rendezvous service at an
    RVS.
 Rendezvous Registration
    A HIP registration for rendezvous service, established between an
    RVS and a rendezvous client.

3. Overview of Rendezvous Server Operation

 Figure 1 shows a simple HIP base exchange without an RVS, in which
 the Initiator initiates the exchange directly with the Responder by
 sending an I1 packet to the Responder's IP address, as per the HIP
 specification [RFC7401].
                    +-----+                +-----+
                    |     |-------I1------>|     |
                    |  I  |<------R1-------|  R  |
                    |     |-------I2------>|     |
                    |     |<------R2-------|     |
                    +-----+                +-----+
        Figure 1: HIP Base Exchange without a Rendezvous Server

Laganier & Eggert Standards Track [Page 3] RFC 8004 HIP Rendezvous Extension October 2016

 The End-Host Mobility and Multihoming with the HIP specification
 [HIP-HOST-MOB] allows a HIP node to notify its peers about changes in
 its set of IP addresses.  This specification presumes initial
 reachability of the two nodes with respect to each other.
 However, such a HIP node MAY also want to be reachable to other
 future correspondent peers that are unaware of its location change.
 The HIP Architecture [HIP-ARCH] introduces RVSs with whom a HIP node
 MAY register its Host Identity Tags (HITs) and current IP addresses.
 An RVS relays HIP packets arriving for these HITs to the node's
 registered IP addresses.  When a HIP node has registered with an RVS,
 it SHOULD record the IP address of its RVS in its DNS record, using
 the HIP DNS resource record type defined in the HIP DNS Extension
 [RFC8005].
                                +-----+
                       +--I1--->| RVS |---I1--+
                       |        +-----+       |
                       |                      v
                    +-----+                +-----+
                    |     |<------R1-------|     |
                    |  I  |-------I2------>|  R  |
                    |     |<------R2-------|     |
                    +-----+                +-----+
         Figure 2: HIP Base Exchange with a Rendezvous Server
 Figure 2 shows a HIP base exchange involving an RVS.  It is assumed
 that HIP node R previously registered its HITs and current IP
 addresses with the RVS, using the HIP Registration Extension
 [RFC8003].  When the Initiator I tries to establish contact with the
 Responder R, it must send the I1 of the base exchange either to one
 of R's IP addresses (if known via DNS or other means) or to one of
 R's RVSs.  Here, I obtains the IP address of R's RVS from R's DNS
 record and then sends the I1 packet of the HIP base exchange to RVS.
 RVS, noticing that the HIT contained in the arriving I1 packet is not
 one of its own, MUST check its current registrations to determine if
 it needs to relay the packets.  Here, it determines that the HIT
 belongs to R and then relays the I1 packet to the registered IP
 address.  R then completes the base exchange without further
 assistance from RVS by sending an R1 directly to the I's IP address,
 as obtained from the I1 packet.  In this specification, the client of
 the RVS is always the Responder.  However, there might be reasons
 (such as NAT and firewall traversal) to allow a client to initiate a
 base exchange through its own RVS.  This specification does not
 address such scenarios, which should be specified in other documents.

Laganier & Eggert Standards Track [Page 4] RFC 8004 HIP Rendezvous Extension October 2016

3.1. Diagram Notation

 Notation       Significance
 --------       ------------
 I, R           I and R are the respective source and destination IP
                addresses in the IP header.
 HIT-I, HIT-R   HIT-I and HIT-R are the Initiator's and the
                Responder's HITs in the packet, respectively.
 REG_REQ        A REG_REQUEST parameter is present in the HIP header.
 REG_RES        A REG_RESPONSE parameter is present in the HIP header.
 FROM:I         A FROM parameter containing the IP address I is
                present in the HIP header.
 RVS_HMAC       An RVS_HMAC parameter containing an Hashed Message
                Authentication Code (HMAC) keyed with the appropriate
                registration key is present in the HIP header.
 VIA:RVS        A VIA_RVS parameter containing the IP address RVS of
                a rendezvous server is present in the HIP header.

3.2. Rendezvous Client Registration

 Before an RVS starts to relay HIP packets to a rendezvous client, the
 rendezvous client needs to register with the RVS to receive
 rendezvous service by using the HIP Registration Extension [RFC8003]
 as illustrated in the following schema:
              +-----+                            +-----+
              |     |            I1              |     |
              |     |--------------------------->|     |
              |     |<---------------------------|     |
              |  I  |         R1(REG_INFO)       | RVS |
              |     |         I2(REG_REQ)        |     |
              |     |--------------------------->|     |
              |     |<---------------------------|     |
              |     |         R2(REG_RES)        |     |
              +-----+                            +-----+
        Rendezvous Client Registering with a Rendezvous Server

Laganier & Eggert Standards Track [Page 5] RFC 8004 HIP Rendezvous Extension October 2016

3.3. Relaying the Base Exchange

 If a HIP node and one of its RVSs have a rendezvous registration, the
 RVSs relay inbound I1 packets (that contain one of the client's HITs)
 by rewriting the IP header.  They replace the destination IP address
 of the I1 packet with one of the IP addresses of the owner of the
 HIT, i.e., the rendezvous client.  They MUST also recompute the IP
 checksum accordingly.
 Because of ingress filtering on the path from the RVS to the client
 [RFC2827] [RFC3013], a HIP RVS SHOULD replace the source IP address,
 i.e., the IP address of I, with one of its own IP addresses.  The
 replacement IP address SHOULD be chosen according to relevant IPv4
 and IPv6 specifications [RFC1122] [RFC6724].  Because this
 replacement conceals the Initiator's IP address, the RVS MUST append
 a FROM parameter containing the original source IP address of the
 packet.  This FROM parameter MUST be integrity protected by an
 RVS_HMAC keyed with the corresponding rendezvous registration
 integrity key [RFC8003].
                                           I1(RVS, R, HIT-I, HIT-R
     I1(I, RVS, HIT-I, HIT-R) +---------+     FROM:I, RVS_HMAC)
     +----------------------->|         |--------------------+
     |                        |   RVS   |                    |
     |                        |         |                    |
     |                        +---------+                    |
     |                                                       V
    +-----+        R1(R, I, HIT-R, HIT-I, VIA:RVS)       +-----+
    |     |<---------------------------------------------|     |
    |     |                                              |     |
    |  I  |            I2(I, R, HIT-I, HIT-R)            |  R  |
    |     |--------------------------------------------->|     |
    |     |<---------------------------------------------|     |
    +-----+             R2(R, I, HIT-R, HIT-I)           +-----+
               Rendezvous Server Rewriting IP Addresses
 This modification of HIP packets at an RVS can be problematic because
 HIP uses integrity checks.  Because the I1 does not include HMAC or
 SIGNATURE parameters, these two end-to-end integrity checks are
 unaffected by the operation of RVSs.
 The RVS SHOULD verify the checksum field of an I1 packet before doing
 any modifications.  After modification, it MUST recompute the
 checksum field using the updated HIP header, which possibly included
 new FROM and RVS_HMAC parameters, and a pseudo-header containing the

Laganier & Eggert Standards Track [Page 6] RFC 8004 HIP Rendezvous Extension October 2016

 updated source and destination IP addresses.  This enables the
 Responder to validate the checksum of the I1 packet "as is", without
 having to parse any FROM parameters.

4. Rendezvous Server Extensions

 This section describes extensions to the HIP Registration Extension
 [RFC8003], allowing a HIP node to register with an RVS for rendezvous
 service and to notify the RVS aware of changes to its current
 location.  It also describes an extension to the HIP specification
 [RFC7401] itself, allowing establishment of HIP associations via one
 or more HIP RVSs.

4.1. RENDEZVOUS Registration Type

 This specification defines an additional registration for the HIP
 Registration Extension [RFC8003] that allows registering with an RVS
 for rendezvous service.
 Number   Registration Type
 ------   -----------------
 1        RENDEZVOUS

4.2. Parameter Formats and Processing

4.2.1. RVS_HMAC Parameter

 The RVS_HMAC is a non-critical parameter whose only difference with
 the HMAC parameter defined in the HIP specification [RFC7401] is its
 "type" code.  This change causes it to be located after the FROM
 parameter (as opposed to the HMAC):
 Type        65500
 Length      Variable.  Length in octets, excluding Type, Length, and
             Padding.
 HMAC        HMAC computed over the HIP packet, excluding the
             RVS_HMAC parameter and any following parameters.  The
             HMAC is keyed with the appropriate HIP integrity key
             (HIP-lg or HIP-gl) established when rendezvous
             registration happened.  The HIP "checksum" field MUST be
             set to zero, and the HIP header length in the HIP common
             header MUST be calculated not to cover any excluded
             parameter when the HMAC is calculated.  The size of the
             HMAC is the natural size of the hash computation
             output depending on the used hash function.

Laganier & Eggert Standards Track [Page 7] RFC 8004 HIP Rendezvous Extension October 2016

 To allow a rendezvous client and its RVS to verify the integrity of
 packets flowing between them, both SHOULD protect packets with an
 added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity
 key established while registration occurred.  A valid RVS_HMAC SHOULD
 be present on every packet flowing between a client and a server and
 MUST be present when a FROM parameter is processed.

4.2.2. FROM Parameter

   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                             Address                           |
  |                                                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Type        65498
  Length      16
  Address     An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
 An RVS MUST add a FROM parameter containing the original source IP
 address of a HIP packet whenever the source IP address in the IP
 header is rewritten.  If one or more FROM parameters are already
 present, the new FROM parameter MUST be appended after the existing
 ones.
 Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC
 protecting the packet integrity, especially the IP address included
 in the FROM parameter.

Laganier & Eggert Standards Track [Page 8] RFC 8004 HIP Rendezvous Extension October 2016

4.2.3. VIA_RVS Parameter

   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                            Address                            |
  |                                                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .                               .                               .
  .                               .                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                            Address                            |
  |                                                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Type        65502
  Length      Variable
  Address     An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
 After the Responder receives a relayed I1 packet, it can begin to
 send HIP packets addressed to the Initiator's IP address, without
 further assistance from an RVS.  For debugging purposes, it MUST
 append a newly created VIA_RVS parameter at the end of the R1 packet
 that contains the IP address of the RVS that relayed the I1 packet.
 Including more than one IP address in the VIA_RVS parameter is
 outside the scope of this specification.  The main goal of using the
 VIA_RVS parameter is to allow operators to diagnose possible issues
 encountered while establishing a HIP association via an RVS.

4.3. Modified Packets Processing

 The following subsections describe the differences of the processing
 of I1 and R1 while an RVS is involved in the base exchange.

4.3.1. Processing Outgoing I1 Packets

 An Initiator SHOULD NOT send an opportunistic I1 with a NULL
 destination HIT to an IP address that is known to be a rendezvous
 server address, unless it wants to establish a HIP association with
 the RVS itself and does not know its HIT.

Laganier & Eggert Standards Track [Page 9] RFC 8004 HIP Rendezvous Extension October 2016

 When an RVS rewrites the source IP address of an I1 packet due to
 egress filtering, it MUST add a FROM parameter to the I1 that
 contains the Initiator's source IP address.  This FROM parameter MUST
 be protected by an RVS_HMAC keyed with the integrity key established
 at rendezvous registration.

4.3.2. Processing Incoming I1 Packets

 When an RVS receives an I1 whose destination HIT is not its own, it
 consults its registration database to find a registration for the
 rendezvous service established by the HIT owner.  If it finds an
 appropriate registration, it relays the packet to the registered IP
 address.  If it does not find an appropriate registration, it drops
 the packet.
 An RVS SHOULD interpret any incoming opportunistic I1 (i.e., an I1
 with a NULL destination HIT) as an I1 addressed to itself and SHOULD
 NOT attempt to relay it to one of its clients.
 When a rendezvous client receives an I1, it MUST validate any present
 RVS_HMAC parameter.  If the RVS_HMAC cannot be verified, the packet
 SHOULD be dropped.  If the RVS_HMAC cannot be verified and a FROM
 parameter is present, the packet MUST be dropped.
 A rendezvous client acting as Responder SHOULD drop opportunistic I1s
 that include a FROM parameter, because this indicates that the I1 has
 been relayed.

4.3.3. Processing Outgoing R1 Packets

 When a Responder replies to an I1 relayed via an RVS, it MUST append
 to the regular R1 header a VIA_RVS parameter containing the IP
 addresses of the traversed RVSs.

4.3.4. Processing Incoming R1 Packets

 The HIP specification [RFC7401] mandates that a system receiving an
 R1 MUST first check to see if it has sent an I1 to the originator of
 the R1 (i.e., the system is in state I1-SENT).  When the R1 is
 replying to a relayed I1, this check SHOULD be based on HITs only.
 In case the IP addresses are also checked, then the source IP address
 MUST be checked against the IP address included in the VIA_RVS
 parameter.

Laganier & Eggert Standards Track [Page 10] RFC 8004 HIP Rendezvous Extension October 2016

5. Security Considerations

 This section discusses the known threats introduced by these HIP
 extensions and the implications on the overall security of HIP.  In
 particular, it argues that the extensions described in this document
 do not introduce additional threats to HIP.
 It is difficult to encompass the whole scope of threats introduced by
 RVSs because their presence has implications both at the IP and HIP
 layers.  In particular, these extensions might allow for redirection,
 amplification, and reflection attacks at the IP layer, as well as
 attacks on the HIP layer itself, for example, man-in-the-middle
 attacks against the HIP base exchange.
 If an Initiator has a priori knowledge of the Responder's host
 identity when it first contacts the Responder via an RVS, it has a
 means to verify the signatures in the HIP base exchange, which
 protects against man-in-the-middle attacks.
 If an Initiator does not have a priori knowledge of the Responder's
 host identity (so-called "opportunistic Initiators"), it is almost
 impossible to defend the HIP exchange against these attacks, because
 the public keys exchanged cannot be authenticated.  The only approach
 would be to mitigate hijacking threats on HIP state by requiring an
 R1 answering an opportunistic I1 to come from the same IP address
 that originally sent the I1.  This procedure retains a level of
 security that is equivalent to what exists in the Internet today.
 However, for reasons of simplicity, this specification does not allow
 the establishment of a HIP association via an RVS in an opportunistic
 manner.

6. IANA Considerations

 [RFC5204], obsoleted by this document, made the following definitions
 and reservations in the "Parameter Types" subregistry under "Host
 Identity Protocol (HIP) Parameters":
 Value   Parameter Type  Length
 -----   --------------  --------
 65498   FROM            16
 65500   RVS_HMAC        variable
 65502   VIA_RVS         variable
 In the "Parameter Types" subregistry under "Host Identity Protocol
 (HIP) Parameters", references to [RFC5204] have been replaced by
 references to this document.

Laganier & Eggert Standards Track [Page 11] RFC 8004 HIP Rendezvous Extension October 2016

 [RFC5204], obsoleted by this document, made the following definition
 and reservation in the "Registration Types" subregistry under "Host
 Identity Protocol (HIP) Parameters":
 Value   Registration Type
 -----   -----------------
 1       RENDEZVOUS
 In the "Registration Types" subregistry under "Host Identity Protocol
 (HIP) Parameters", references to [RFC5204] have been replaced by
 references to this document.

7. References

7.1. Normative References

 [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
            Communication Layers", STD 3, RFC 1122,
            DOI 10.17487/RFC1122, October 1989,
            <http://www.rfc-editor.org/info/rfc1122>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
            "Default Address Selection for Internet Protocol Version 6
            (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
            <http://www.rfc-editor.org/info/rfc6724>.
 [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
            Henderson, "Host Identity Protocol Version 2 (HIPv2)",
            RFC 7401, DOI 10.17487/RFC7401, April 2015,
            <http://www.rfc-editor.org/info/rfc7401>.
 [RFC8003]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
            Registration Extension", RFC 8003, DOI 10.17487/RFC8003,
            October 2016, <http://www.rfc-editor.org/info/rfc8003>.
 [RFC8005]  Laganier, J., "Host Identity Protocol (HIP) Domain Name
            System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
            October 2016, <http://www.rfc-editor.org/info/rfc8005>.

Laganier & Eggert Standards Track [Page 12] RFC 8004 HIP Rendezvous Extension October 2016

7.2. Informative References

 [HIP-ARCH] Moskowitz, R. and M. Komu, "Host Identity Protocol
            Architecture", Work in Progress, draft-ietf-hip-rfc4423-
            bis-14, June 2016.
 [HIP-HOST-MOB]
            Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
            the Host Identity Protocol", Work in Progress, draft-ietf-
            hip-rfc5206-bis-14, October 2016.
 [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
            Defeating Denial of Service Attacks which employ IP Source
            Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
            May 2000, <http://www.rfc-editor.org/info/rfc2827>.
 [RFC3013]  Killalea, T., "Recommended Internet Service Provider
            Security Services and Procedures", BCP 46, RFC 3013,
            DOI 10.17487/RFC3013, November 2000,
            <http://www.rfc-editor.org/info/rfc3013>.
 [RFC5204]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
            Rendezvous Extension", RFC 5204, DOI 10.17487/RFC5204,
            April 2008, <http://www.rfc-editor.org/info/rfc5204>.

Laganier & Eggert Standards Track [Page 13] RFC 8004 HIP Rendezvous Extension October 2016

Appendix A. Changes from RFC 5204

 o  Updated HIP references to revised HIP specifications.

Acknowledgments

 The following people have provided thoughtful and helpful discussions
 and/or suggestions that have improved this document: Marcus Brunner,
 Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Juergen
 Quittek, Justino Santos, Simon Schuetz, Tim Shepard, Kristian Slavov,
 and Martin Stiemerling.
 Lars Eggert has received funding from the European Union's Horizon
 2020 research and innovation program 2014-2018 under grant agreement
 No. 644866.  This document reflects only the authors' views, and the
 European Commission is not responsible for any use that may be made
 of the information it contains.
 Thanks to Joel M. Halpern for performing the Gen-ART review of this
 document as part of the publication process.

Authors' Addresses

 Julien Laganier
 Luminate Wireless, Inc.
 Cupertino, CA
 United States of America
 Email: julien.ietf@gmail.com
 Lars Eggert
 NetApp
 Sonnenallee 1
 Kirchheim  85551
 Germany
 Phone: +49 151 12055791
 Email: lars@netapp.com
 URI:   http://eggert.org

Laganier & Eggert Standards Track [Page 14]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8004.txt · Last modified: 2016/10/14 23:29 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki