



IKEv2 Mobility and Multihoming                              U. Schilcher
(mobike)                                                   H. Tschofenig
Internet-Draft                                                  F. Muenz
Expires: January 18, 2006                                     Siemens AG
                                                           July 17, 2005


                      MOBIKE Extensions for PF_KEY
             draft-schilcher-mobike-pfkey-extension-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   PF_KEY is a generic key management API used for communication between
   a trusted user level key management daemon and a key engine within
   the operating system.  With the extension of IKEv2 for mobility and
   multihoming (MOBIKE) the existing capabilities of PF_KEY with regard
   to the creation, maintenance and deletion of security associations
   became insufficient.  This document defines an extension to update an
   entity in the security association database.  Additionally, it is



Schilcher, et al.       Expires January 18, 2006                [Page 1]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


   necessary to reflect the newly offered integrity and encryption
   algorithms with IKEv2 in PF_KEY.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   IPsec SA Update  . . . . . . . . . . . . . . . . . . . . . .   5
   4.   SA Extension . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.   SPD Update . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.   Algorithm Types  . . . . . . . . . . . . . . . . . . . . . .  13
   7.   Traffic Selector Extensions  . . . . . . . . . . . . . . . .  15
   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  16
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  17
   10.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  18
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  19
     11.1   Normative References . . . . . . . . . . . . . . . . . .  19
     11.2   Informative References . . . . . . . . . . . . . . . . .  19
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  20
        Intellectual Property and Copyright Statements . . . . . . .  21































Schilcher, et al.       Expires January 18, 2006                [Page 2]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


1.  Introduction

   PF_KEY [1] is a generic key management API used for communication
   between a trusted user level key management daemon and a key engine
   within the operating system.  With the extension of IKEv2 for
   mobility and multihoming (MOBIKE) [12] the existing capabilities of
   PF_KEY with regard to the creation, maintenance and deletion of
   security associations became insufficient.  If an IKEv2
   implementation [13] supports MOBIKE, some additional interaction with
   the SAD and the SPD has to be provided.  This includes additional
   operations on the security policy database (SPD), such as creation,
   update and deletion of SPD entries, and the possibility to update
   addresses for already existing SAs in the security association
   database (SAD).  Since the PF_KEY interface in the current version
   does not support this operations, some extensions have to be defined.

   This document is partially based on PF_KEY extensions provided the
   KAME stack (see also [14]), which go beyond those described in [1].
   The authors think that it is necessary to update the original RFC
   2367 PF_KEY version to reflect the state-of-the-art implementations.































Schilcher, et al.       Expires January 18, 2006                [Page 3]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


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 [2].














































Schilcher, et al.       Expires January 18, 2006                [Page 4]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


3.  IPsec SA Update

   The first extension allows an IKEv2 implementation to update the
   addresses of an existing security association (SA) dynamically.
   Updating IPsec SAs is one of the side-effect of the IKE-SA update, a
   feature provided by MOBIKE [12].  PF_KEY defines a number of
   messages, namely SADB_GETSPI, SADB_UPDATE, SADB_ADD, SADB_DELETE,
   SADB_GET, SADB_ACQUIRE, SADB_REGISTER, SADB_EXPIRE, SADB_FLUSH and
   SADB_DUMP, for interaction between the key management daemon and the
   key engine in the operating system.

   In Section 3.1.2 of [1] an SADB_UPDATE message is described for
   updating all data stored for an existing SA.  The only parameters,
   which cannot be updated using an SADB_UPDATE message, are the
   Security Parameter Index (SPI), the source and destination IP
   addresses.  The reason for this design decision might be based on the
   IPsec SA identification, which included these parameters to uniquely
   select a given security association.  This aspect can, however, be
   seen as historic.  In IKEv2, without the use of MOBIKE, theses
   parameters would not change.

   To allow an IKEv2 key management daemon to change the addresses of an
   existing SA, a new message type has to be introduced:
   SADB_X_ADDRUPDATE.  The notation of SADB_X is intended to outline an
   extention to the current API defined in [1].  Required symbols or
   structures in the PF_KEYv2 name space that are not described in [1]
   should therefore start with "SADB_X_" or "sadb_x_".

   The format of the SADB_X_ADDRUPDATE message is:

   <base, SA(*), address(SD), new_address(SD)>

   The kernel responds with a message of the form:

   <base, SA(*), address(SD), new_address(SD)>

   The meaning of the payloads of the message is the following: "base"
   defines the default message header, "SA(*)" identifies the security
   association to be updated, where (*) indicates that the SA payload
   contains only the SPI of it, "address(SD)" contains the source and
   the destination addresses of the existing SA and "new_address(SD)"
   the new source and destination addresses.  For a more detailed
   description of the payloads see [1].  For the new_address(SD)
   attribute new payload types SADB_X_EXT_NEW_ADDRESS_SRC and
   SADB_X_EXT_NEW_ADDRESS_DST are needed.  These payloads have the same
   content as the SADB_EXT_ADDRESS_SRC and SADB_EXT_ADDRESS_DST
   payloads.




Schilcher, et al.       Expires January 18, 2006                [Page 5]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


   If the kernel receives a SADB_X_ADDRUPDATE message it immediately
   updates the SA identified by the SPI in the message.  If more than
   one SA has to be updated, several SADB_X_ADDRUPDATE messages have to
   be sent since each SA payload can only contain one SPI.

   In an error case, like for instance a malformed message, the kernel
   will respond with:

   <base>

   The "errno" field of the message will provide further information
   about the error.







































Schilcher, et al.       Expires January 18, 2006                [Page 6]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


4.  SA Extension

   In case a protected packet arrives with an unknown SPI value, for
   which no corresponding SA exists, the kernel actively sends a
   SADB_ACQUIRE to all listening applications.  Using the information
   given in the SADB_ACQUIRE, the applications are able to quickly
   create a SA, while the triggering packet is still in the kernel
   buffer.  The important information that are missing, are the traffic
   selector (TS) addresses, which are negotiated by IKEv2 using the TS
   payloads.

   Since the TS addresses are only stored inside the SPD, they have to
   be read from there (see section Section 5).  For that purpose the ID,
   which identifies the SPD entry, to which the new SA corresponds, has
   to be known.  The proposed way to pass that ID from the kernel to the
   IKEv2 implementation is in using the following extension of the
   PF_KEY interface.

   An SA2 payload has to be included in the SADB_ACQUIRE message, which
   has to following content:

   struct sadb_x_sa2 {
           uint16_t        sadb_x_sa2_len;
           uint16_t        sadb_x_sa2_exttype;
           uint8_t         sadb_x_sa2_mode;
           uint8_t         sadb_x_sa2_reserved1;
           uint16_t        sadb_x_sa2_reserved2;
           uint32_t        sadb_x_sa2_sequence;
           uint32_t        sadb_x_sa2_reqid;
   } __attribute__((packed));
   /* sizeof(struct sadb_x_sa2) == 16 */

   sadb_x_sa2_len:

      The sadb_x_sa2_len contains the length of the structure in 8 Byte
      blocks.

   sadb_x_sa2_exttype:

      This field contains the value identifying the SADB_X_SA2 payload.

   sadb_x_sa2_mode:

      The sadb_x_sa2_mode field identifies the IPsec mode (i.e., tunnel
      or transport mode).






Schilcher, et al.       Expires January 18, 2006                [Page 7]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


   sadb_x_sa2_sequence:

      The sadb_x_sa2_sequence field contains the ID of the corresponding
      SPD entry.

   sadb_x_sa2_reqid:

      The request ID for that message.


   This payload can also be added to SADB_ADD and SADB_UPDATE messages
   to tell the kernel whether the SA to be generated is a transport or a
   tunnel mode SA.  If no SADB_X_SA2 payload is present, all SAs created
   will only support tunnel mode.





































Schilcher, et al.       Expires January 18, 2006                [Page 8]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


5.  SPD Update

   For manipulating SPD entries, new PF_KEY messages have to be
   introduced (see also the KAME IPsec implementation).

   Note that specifying SPD updates is problematic since the KAME IPsec
   extensions have never been standardized.  As a consequence, this text
   does not extend PF_KEY [1] itself.

   These message types are quite similar to the message types used to
   manipulate the entries in the SAD.  The following new message types
   are needed:


   SADB_X_SPDADD:

      To add a new entry to the SPD, the key management daemon needs to
      send a SADB_X_SPDADD message to the kernel.  The format of the
      message is:

      <base, policy, address(SD), [lifetime(HS)]>

      The kernel responds with a message of the form:

      <base, policy, address(SD), [lifetime(HSC)]>

      The meaning of the payloads, except for the policy payload, can be
      found in [1].  The policy payload contains all specific
      information about the new entry:

   struct sadb_x_policy {
           uint16_t        sadb_x_policy_len;
           uint16_t        sadb_x_policy_exttype;
           uint16_t        sadb_x_policy_type;
           uint8_t         sadb_x_policy_dir;
           uint8_t         sadb_x_policy_reserved;
           uint32_t        sadb_x_policy_id;
           uint32_t        sadb_x_policy_reserved2;
   } __attribute__((packed));
   /* sizeof(struct sadb_x_policy) == 16 */

      The sadb_x_policy_len field contains the length of the payload in
      8 Byte blocks and sadb_x_policy_exttype contains the value
      SADB_X_SPDADD.  The type of the SA is indicated by the
      sadb_x_policy_type field (e.g., IPsec SA) and the
      sadb_x_policy_dir field indicates the direction of the SA (the
      possibilities are IPSEC_DIR_INBOUND, IPSEC_DIR_OUTBOUND and
      IPSEC_DIR_FWD).  The sadb_x_policy_id field contains a value which



Schilcher, et al.       Expires January 18, 2006                [Page 9]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


      is unique for each SPD entry.  It should be set to zero for a
      SADB_X_SPDADD message, since the kernel is going to fill this
      value in.  This structure is followed by one or more ipsecrequest
      structures, one for each protocol used by the new SPD entry:

   struct sadb_x_ipsecrequest {
           uint16_t        sadb_x_ipsecrequest_len;
           uint16_t        sadb_x_ipsecrequest_proto;
           uint8_t         sadb_x_ipsecrequest_mode;
           uint8_t         sadb_x_ipsecrequest_level;
           uint16_t        sadb_x_ipsecrequest_reserved1;
           uint32_t        sadb_x_ipsecrequest_reqid;
           uint32_t        sadb_x_ipsecrequest_reserved2;
   } __attribute__((packed));
   /* sizeof(struct sadb_x_ipsecrequest) == 16 */

      sadb_x_ipsecrequest_len:

         The sadb_x_ipsecrequest_len again contains the length of the
         structure including optional extensions, but this time in
         bytes.

      sadb_x_ipsecrequest_proto:

         The sadb_x_ipsecrequest_proto field identifies the protocol
         used for the current structure (e.g., ESP or AH).

      sadb_x_ipsecrequest_mode:

         The sadb_x_ipsecrequest_mode field identifies the IPsec mode
         (i.e., tunnel or transport mode), which can be different for
         each protocol.

      sadb_x_ipsecrequest_level:

         The sadb_x_ipsecrequest_level field contains one of the
         following values: 'default', 'use', 'require' or 'unique'.  It
         defines how and when a corresponding SA is used.  The value
         'use' means that an SA is used if available, otherwise the
         kernel keeps its normal operation.  If 'require' is specified,
         it means that an SA is required for each packet matching to the
         policy entry.  The value 'unique' has the same meaning as
         require except that the policy entry is bound to exactly one
         outbound SA.







Schilcher, et al.       Expires January 18, 2006               [Page 10]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


      sadb_x_ipsecrequest_reqid:

         An ID for that SA can be passed to the kernel in the
         sadb_x_ipsecrequest_reqid field.


      If tunnel mode is specified, the sadb_x_ipsecrequest structure is
      followed by two sockaddr structures that define the tunnel
      endpoint addresses.  In the case that transport mode is used, no
      additional addresses are specified.  The next payloads of the
      message are the source and destination addresses of the
      communication to be protected.  In tunnel mode it is possible to
      use address ranges instead of single address pairs to protect the
      traffic of whole subnets with one SPD entry.  It is also possible
      to specify hard and soft lifetimes for policy entries, but these
      payloads are optional.  In the response from the kernel a hard, a
      soft and a current lifetime are always present.  The semantics are
      the same as for SAD entries (see [1]).


   SADB_X_SPDUPDATE:

      If an existing SPD entry should be updated, the IKEv2
      implementation sends a SADB_X_SPDUPDATE message to the kernel.
      This massage has the following format:

      <base, policy, address(SD),[lifetime(HS)]>

      The kernel responds with a message of the form:

      <base, policy, address(SD), [lifetime(HSC)]>

      The meaning of the payloads is the same as for the SADB_X_SPDADD
      message.  All the content of a SPD entry can be changed except the
      sadb_x_policy_id field and the source/destination addresses, which
      are the inner addresses in tunnel mode.  However, the tunnel
      endpoint addresses, which only exist in tunnel mode, can be
      changed using a SADB_X_SPDUPDATE message.


   SADB_X_SPDDELETE:

      A SADB_X_SPDDELETE message is sent to the kernel in the case that
      an existing SPD entry should be deleted.  The entry is identified
      by the policy data and the source and destination address.  The
      message has the following format:





Schilcher, et al.       Expires January 18, 2006               [Page 11]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


      <base, policy, address(SD)>

      The kernel responds with a message of the form:

      <base, policy, address(SD), [lifetime(HSC)]>

      If no corresponding entry can be found, the kernel returns a
      message containing only the base header with the errno value set
      appropriately.


   SADB_X_SPDGET:

      If the content of an existing SPD entry is needed, a SADB_X_SPDGET
      message has to be sent to the kernel.  The entry is identified by
      the sadb_x_policy_id entry in the sadb_x_policy structure.  This
      id can obtained for example from a SADB_ACQUIRE message.  The
      format of a SADB_X_SPDGET message is:

      <base, policy>

      The kernel responds with a message of the form:

      <base, policy, address(SD), [lifetime(HSC)]>

      If no entry has been found, the kernel returns an errno value in
      the base header.


   SADB_X_SPDDUMP:

      If the kernel receives a SADB_X_SPDDUMP message, it prints out all
      existing SPD entries on the console.  The message format is:

      <base>

   SADB_X_SPDFLUSH:

      To delete all SPD entries a SADB_X_SPDFLUSH message has to be sent
      to the kernel.  The format of the message is:

      <base>









Schilcher, et al.       Expires January 18, 2006               [Page 12]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


6.  Algorithm Types

   This document defines an IANA registry for the IKEv2 defined
   cryptographic algorithms and thereby extends the algorithms defined
   by PF_KEY (see Section 3.5 of [1]).  The same set of algorithms is
   available to MOBIKE.

   The following algorithms have been defined already in PF_KEY, Section
   3.5 of [1]):

               /* Integrity (Authentication) Algorithms */

   PF_KEY Algorithm Name       Value       Description
   ---------------------------+---------+-----------------------
   SADB_AALG_NONE             |   0     | not used
   SADB_AALG_MD5HMAC          |   2     | HMAC-MD5-96
   SADB_AALG_SHA1HMAC         |   3     | HMAC-SHA-1-96


              /* Encryption Algorithms */

   PF_KEY Algorithm Name        Value       Description
   ---------------------------+---------+-----------------------
   SADB_EALG_NONE             |   0     | not used
   SADB_EALG_DESCBC           |   2     | DES in CBC mode
   SADB_EALG_3DESCBC          |   3     | TripleDES in CBC mode
   SADB_EALG_NULL             |   11    | NULL encryption

   The algorithm for SADB_AALG_MD5_HMAC is defined in [3].  The
   algorithm for SADB_AALG_SHA1HMAC is defined in [4].  The algorithm
   for SADB_EALG_DESCBC is defined in [5].  SADB_EALG_NULL is the NULL
   encryption algorithm, defined in [6].  The SADB_EALG_NONE value is
   not to be used in any security association except those which have no
   possible encryption algorithm in them (e.g.  IPsec AH).

   This document enhances this list with the following algorithms:















Schilcher, et al.       Expires January 18, 2006               [Page 13]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


               /* Integrity (Authentication) Algorithms */

   PF_KEY Algorithm Name        Value       Description
   ---------------------------+---------+-----------------------
   SADB_AALG_AESXCBCMAC       |   4     | AES-XCBC-MAC-96
   SADB_X_AALG_SHA2_256HMAC   |   5     | SHA2-HMAC-256
   SADB_X_AALG_SHA2_384HMAC   |   6     | SHA2-HMAC-384
   SADB_X_AALG_SHA2_512HMAC   |   7     | SHA2-HMAC-512
   SADB_X_AALG_RIPEMD160HMAC  |   8     | HMAC-RIPEMD-160-96


               /* Encryption algorithms */

   PF_KEY Algorithm Name        Value       Description
   ---------------------------+---------+-----------------------
   SADB_EALG_AESCBC128        |   12    | AES with
                              |         | 128-bit keys in CBC mode
   SADB_X_EALG_CASTCBC        |   6     | CAST in CBC mode
   SADB_X_EALG_BLOWFISHCBC    |   7     | BLOWFISH in CBC mode
   SADB_X_EALG_AESCBC         |   12    | AES in CBC mode
   SADB_X_EALG_AESCTR         |   13    | AES Counter Mode

   AES-XCBC-MAC-96 is defined in [7] and AES with 128-bit keys in CBC
   mode is defined in [8].  AES counter mode has been defined for usage
   with IPsec ESP (see [9]).  HMAC-RIPEMD-160-96 is defined in [10].

   Note that compression algorithms also need to be considered.  This
   document does not list them, however.























Schilcher, et al.       Expires January 18, 2006               [Page 14]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


7.  Traffic Selector Extensions

   Information about Traffic Selectors should also be added to a updated
   version of PF_KEY [1].  This is left for future work.















































Schilcher, et al.       Expires January 18, 2006               [Page 15]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


8.  IANA Considerations

   This document defines an IANA registry for the cryptographic
   algorithms used within PF_KEY:

   TBD













































Schilcher, et al.       Expires January 18, 2006               [Page 16]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


9.  Security Considerations

   This document describes an extension to PF_KEY [1] and therefore
   inherits its security properties.  Since this interface allows
   existing entries in the security association database (and the
   security policy database) to be created, updated or deleted it needs
   to be ensured that only trusted and privileged processes are allowed
   to this interface.











































Schilcher, et al.       Expires January 18, 2006               [Page 17]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


10.  Acknowledgments

   The authors would like to thank Bao G. Phan for his initial PF_KEY
   implementation at US Naval Research Lab and the developers of FreeBSD
   for providing their PF_KEY implementation and for extending it for
   policy support, as well as R.J. Atkinson and Dan McDonald.













































Schilcher, et al.       Expires January 18, 2006               [Page 18]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


11.  References

11.1  Normative References

   [1]   McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management
         API, Version 2", RFC 2367, July 1998.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", March 1997.

   [3]   Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and
         AH", RFC 2403, November 1998.

   [4]   Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
         and AH", RFC 2404, November 1998.

   [5]   Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm
         With Explicit IV", RFC 2405, November 1998.

   [6]   Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
         Use With IPsec", RFC 2410, November 1998.

   [7]   Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and
         Its Use With IPsec", RFC 3566, September 2003.

   [8]   Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
         Algorithm and Its Use with IPsec", RFC 3602, September 2003.

   [9]   Housley, R., "Using Advanced Encryption Standard (AES) Counter
         Mode With IPsec Encapsulating Security Payload (ESP)",
         RFC 3686, January 2004.

   [10]  Keromytis, A. and N. Provos, "The Use of HMAC-RIPEMD-160-96
         within ESP and AH", RFC 2857, June 2000.

   [11]  Hoffman, P., "Cryptographic Suites for IPsec",
         draft-ietf-ipsec-ui-suites-06 (work in progress), April 2004.

11.2  Informative References

   [12]  Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol",
         draft-ietf-mobike-design-02 (work in progress), February 2005.

   [13]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
         draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.

   [14]   ,  ., "PF_KEY Extensions for IPsec Policy Management in KAME
         Stack, available at http://www.kame.net/newsletter/20021210/



Schilcher, et al.       Expires January 18, 2006               [Page 19]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


         (February 2005)", 12 2002.


Authors' Addresses

   Udo Schilcher
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   Email: udo.schilcher@edu.uni-klu.ac.at


   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com


   Franz Muenz
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   Email: Franz.Muenz@thirdwave.de





















Schilcher, et al.       Expires January 18, 2006               [Page 20]

Internet-Draft        MOBIKE Extensions for PF_KEY             July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Schilcher, et al.       Expires January 18, 2006               [Page 21]


