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

Versions: 00

Host Identity Protocol                                        D. Lagutin
Internet-Draft                        Helsinki Institute for Information
Intended status: Experimental                                 Technology
Expires: January 4, 2011                                    July 3, 2010


Packet Level Authentication (PLA) Extensions for Host Identity Protocol
                                 (HIP)
                        draft-lagutin-hip-pla-00

Abstract

   This document defines extensions to provide Packet Level
   Authentication (PLA) functionality for the HIP protocol.  PLA
   provides strong hop-by-hop security features that allow intermediate
   nodes to detect the hostile traffic quickly, and drop the traffic
   before it reaches the destination and can consume resources in the
   target network.

   Unlikely other similar solutions, PLA does not require excessive
   signaling or state in verifying nodes, and is path-independent,
   making it suitable for dynamic environments, such as ad-hoc networks.

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

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 4, 2011.

Copyright Notice




Lagutin                  Expires January 4, 2011                [Page 1]


Internet-Draft                   HIP PLA                       July 2010


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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.



























Lagutin                  Expires January 4, 2011                [Page 2]


Internet-Draft                   HIP PLA                       July 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  PLA-HIP Protocol Overview . . . . . . . . . . . . . . . . . . . 4
     2.1.  Security Mechanisms . . . . . . . . . . . . . . . . . . . . 5
     2.2.  Related Solutions . . . . . . . . . . . . . . . . . . . . . 5
   3.  Packet Processing . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  Packet Formats  . . . . . . . . . . . . . . . . . . . . . . . . 6
     4.1.  Definition of the PLA_HIP Parameter . . . . . . . . . . . . 6
   5.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8


































Lagutin                  Expires January 4, 2011                [Page 3]


Internet-Draft                   HIP PLA                       July 2010


1.  Introduction

   Packet Level Authentication (PLA) [LAG08] is a novel security
   solution that aims to provide availability and integrity protection
   on the network layer.  PLA offers hop-by-hop authentication: any
   intermediate node has the ability to independently verify
   authenticity and integrity of the traffic, without pre-established
   trust relationships with the sender or other nodes that handled the
   traffic.  The good analogy to PLA is a paper currency: anyone can
   verify validity of the paper bill using built-in security measures
   such as watermark and hologram, there is no need to contact the bank
   that has issued the bill.

   Similarly, PLA allows intermediate nodes to detect modified, delayed,
   and duplicated packets simply by looking at the packet's contents.
   This protects the recipient from denial-of-service attacks, since
   such packets can be dropped immediately before they can reach the
   destination, and cause a load to the recipient or the recipient's
   network.  Furthermore, strong security mechanisms offered by PLA have
   additional uses.  They can be used to implement simple and secure
   user authentication, since there is often no need for puzzle
   mechanisms or to contact external authentication servers.

   PLA achieves it goals by adding a cryptographic signature and other
   fields to the packet's header.  PLA utilizes elliptic curve
   cryptography (ECC) due to its compact key and signature sizes, but
   can also work with other cryptographic solutions.  While the public
   key signature verification is resource intensive operation, it can be
   performed at wire-speed with a dedicated hardware acceleration
   [FOR08].

   We feel that combining PLA with HIP is advantageous, since both
   technologies are based on cryptographic operations and provide
   different sets of features.  PLA offers hop-by-hop authentication and
   integrity protection, and depending on local policies it can make the
   HIP base exchange unnecessary in some cases.  While HIP provides end-
   to-end confidentiality and security.


2.  PLA-HIP Protocol Overview

   Packet Level Authentication (PLA) Extensions for Host Identity
   Protocol (HIP) basically add PLA's features, such as a hop-by-hop
   integrity protection, to HIP using a new HIP parameter (PLA_HIP).







Lagutin                  Expires January 4, 2011                [Page 4]


Internet-Draft                   HIP PLA                       July 2010


2.1.  Security Mechanisms

   Following PLA's security mechanisms are included in the PLA-HIP
   extensions, and MUST be added to the PLA_HIP parameter by the sender:

   1.  The sender's cryptographic identity (public key) and the
   signature over the packet.  The signature protects packet's integrity
   and should be calculated over the whole packet ignoring the fields
   that may change during the lifetime of the packet.  If the signature
   verification fails, the packet MUST be dropped.

   While PLA-HIP can utilize any public key algorithms including RSA and
   DSA, using Elliptic Curve Digital Signature Algorithm (ECDSA) is
   recommended due to its low key and signature sizes.

   2.  Timestamp.  The aim of the timestamp is provide protection
   against replay attacks that use delayed packets.  Efficient usage of
   the timestamp field requires loosely synchronized clocks in the
   network.  Network's policy decides how strictly the timestamp is
   enforced.  For example, in a public network differences of several
   seconds can be tolerated.

   3.  The sequence number is a monotonically increasing number that
   allow intermediate nodes to detect duplicated packets, and packets
   that are significantly out-of-order.

   It is important to note that performing signature and other above
   mentioned checks is optional.  The recipient and intermediate nodes
   can decide which checks to perform.  For example, some nodes may opt
   to verify only the timestamp and sequence number fields, ignoring the
   signature field.  Therefore PLA-HIP can also be supported by devices
   with a limited computing power.

   PLA also offers additional security mechanisms, such as trusted third
   parties that act as certificate authorities (CAs) and authorize nodes
   in the network.  For simplicity, they have been omitted from this
   version of the draft.

2.2.  Related Solutions

   The functionality provided by PLA-HIP is somehow related to HICCUPS
   [I-D.ietf-hip-hiccups], SAVAH [I-D.kuptsov-sava-hip], and HIP
   certificates [I-D.ietf-hip-cert].  The biggest difference is that
   PLA-HIP is a path independent solution that does not use
   acknowledgment messages, and does not require state for the integrity
   protection in verifying nodes.  Since each packet can be verified
   independently, PLA-HIP is suitable for multihoming and dynamic
   network environments.



Lagutin                  Expires January 4, 2011                [Page 5]


Internet-Draft                   HIP PLA                       July 2010


3.  Packet Processing

   The following diagram in Figure 1, shows an example how the PLA-HIP
   packet is processed in a node.  The order of verification steps is
   not strict, and can be decided by the verifier.  PLA-HIP packets are
   considered to be fully valid if they pass all checks, however, in
   some cases nodes may forward packets even though they have failed
   timestamp or sequence number checks.

     (In)         +----------------+            OK
   -------------> |Verify timestamp| ----------------------+
                  +----------------+                       |
                          |                                |
                          | Fail                           |
                          |                                |
                          v                                v
                    /-----------\     Fail      +----------------------+
                    |Drop packet| <------------ |Verify sequence number|
                    \-----------/               +----------------------+
                          ^                                |
                          |                                |  OK
                          | Fail                           |
                          |                                |
            OK    +----------------+                       |
   <------------- |Verify signature|-----------------------+
     (Out)        +----------------+


                                 Figure 1


4.  Packet Formats

   In addition to the basic HIP headers, the PLA-HIP packet contains
   sender's public key, signature, and timestamp and sequnce number
   fields provided by the PLA_HIP parameter.  Basically the PLA-HIP
   packet can be expressed as:

   IP ( HIP ( HOST_ID, PLA_HIP, HIP_SIGNATURE) PAYLOAD )

   Where HOST_ID and HIP_SIGNATURE parameters are defined in Sections
   5.2.8 and 5.2.11 of [RFC5201].  And the PLA_HIP parameter is defined
   in Section 4.1.

4.1.  Definition of the PLA_HIP Parameter

   The following is the definition of the PLA_HIP parameter:




Lagutin                  Expires January 4, 2011                [Page 6]


Internet-Draft                   HIP PLA                       July 2010


   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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Timestamp                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

   Both the timestamp and sequence number fields are 32 bits long.


5.  Discussion


6.  IANA Considerations

   No IANA considerations.


7.  Security Considerations

   No security considerations.


8.  Acknowledgements

   Thanks to Miika Komu for his helpful comments and suggestions.


9.  References

9.1.  Normative References

   [I-D.ietf-hip-cert]
              Heer, T. and S. Varjonen, "HIP Certificates",
              draft-ietf-hip-cert-03 (work in progress), April 2010.

   [I-D.ietf-hip-hiccups]
              Camarillo, G. and J. Melen, "HIP (Host Identity Protocol)
              Immediate Carriage and Conveyance of Upper- layer Protocol
              Signaling (HICCUPS)", draft-ietf-hip-hiccups-02 (work in
              progress), March 2010.

   [I-D.kuptsov-sava-hip]



Lagutin                  Expires January 4, 2011                [Page 7]


Internet-Draft                   HIP PLA                       July 2010


              Kuptsov, D. and A. Gurtov, "SAVAH: Source address
              validation architecture with Host Identity Protocol",
              draft-kuptsov-sava-hip-01 (work in progress), March 2009.

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

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

9.2.  Informative References

   [FOR08]    Forsten, J., "Packet Level Authentication - Hardware
              Subtask Final Report, Technical report", May 2008, <http:/
              /www.tcs.hut.fi/Software/PLA/new/doc/
              PLA_HW_final_report.pdf>.

   [LAG08]    Lagutin, D., "Redesigning Internet - The Packet Level
              Authentication architecture, Licentiate's thesis",
              Jun 2008, <http://www.tcs.hut.fi/Software/PLA/new/doc/
              Lagutin-Redesigning%20Internet-
              The%20Packet%20Level%20Authentication%20architecture.pdf>.


Author's Address

   Dmitrij Lagutin
   Helsinki Institute for Information Technology
   Metsanneidonkuja 4
   Helsinki
   Finland

   Phone: +358 9 47001
   Fax:   +358 9 694 9768
   Email: dmitrij.lagutin@hiit.fi
















Lagutin                  Expires January 4, 2011                [Page 8]


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