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

Versions: 00 01

Internet Engineering Task Force                               D. Kuptsov
Internet-Draft                                                 A. Gurtov
Intended status: Informational        Helsinki Institute for Information
Expires: September 7, 2009                                    Technology
                                                                   J. Bi
                                                     Tsinghua Univeristy
                                                           March 6, 2009


    SAVAH: Source address validation architecture with Host Identity
                                Protocol
                       draft-kuptsov-sava-hip-01

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 September 7, 2009.

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.





Kuptsov, et al.         Expires September 7, 2009               [Page 1]


Internet-Draft                    SAVAH                       March 2009


Abstract

   This document describes an architecture for the source address
   validation with help of Host Identity Protocol (HIP), SAVAH.  The
   architecture utilizes the properties of cryptographically strong
   protocol to authenticate an originator of a network communication.
   In addition this architecture offers network access control, data
   protection, host mobilty and multihoming features and is suitable for
   the wireless networks.  The proposed, architecture is the first-hop
   router solution, meaning that it should be deployed on the router
   placed on the edge of a local network topology.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  SAVAH protocol overview  . . . . . . . . . . . . . . . . . . .  4
     2.1.  SAVAH router discovery and registration  . . . . . . . . .  5
     2.2.  Source address validation  . . . . . . . . . . . . . . . .  6
     2.3.  SAVAH tunneling mode . . . . . . . . . . . . . . . . . . .  8
   3.  Packet format  . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   5.  Credits  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Normative References . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14


























Kuptsov, et al.         Expires September 7, 2009               [Page 2]


Internet-Draft                    SAVAH                       March 2009


1.  Introduction

   This document specifies an extension to Host Identity Protocol (HIP)
   RFC 4423 [RFC4423] and its component (i.e.  HIP firewall) to perform
   per packet source address validation and authentication.  The
   extension provides means to authenticate the traffic using properties
   of cryptographic algorithms.  It is assumed that this approach is to
   be implemented on the edge, or first-hop, router of the local
   network.  The approach in this document should be easily integrated
   with Source Address Validation Architecture (SAVA) specified in
   RFC5210 [RFC5210] and provide an alternative for a CGA based Source
   Address Authorization and Authentication (CSA) Mechanism
   [I-D.bi-savi-csa].

   This document assumes that the solution is tailored to validate the
   source addresses only of the nodes that belong to the same network.
   Traffic generated from the hosts from outside network is not checked,
   validated or authenticated, meaning that some other solutions are
   needed to be used to achieve this goal.

   To authenticate the traffic using HIP the following approaches can be
   used:

   o  First propose, when both communicating peers are HIP enabled.
      Then HIP firewall (which is in fact should be deployed on the edge
      of the local subnetwork) tracks base exchange signaling packets
      from of all hosts that try to communicate with hosts outside the
      local subnetwork and only lets through packets with valid HITs and
      IP addresses.  Later data packets are sent in ESP encapsulated
      packets so that the firewall can check SPI values of the packets
      and drop those that does not match previously seen base exchange.
      The shortcoming of this approach is requirement of universal
      deployment of HIP.

   o  Secondly, hosts that are inside the local subnetwork, including
      first-hop router, assumed to support HIP with SAVAH extension.
      This document focuses on a description of SAVAH extension.

   o  Finally, HIP tunneling approach can be used.  It is thought to be
      less efficient in terms of performance, but can provide better
      security and mobility support to the wireless clients.  The client
      creates a tunnel between himself and the SAVAH router using HIP
      base exchange and SAVAH extension.  Later all traffic is forwarded
      through this tunnel to the Internet.







Kuptsov, et al.         Expires September 7, 2009               [Page 3]


Internet-Draft                    SAVAH                       March 2009


2.  SAVAH protocol overview

   This section describes the SAVAH extension.  It illustrates and
   explains the signaling and data packets, as well as it discusses the
   source address validation mechanism.

      Client               DHCP    Router                          Peer
         |  Request network  |        |                              |
         |   configuration   |        |                              |
         |------------------>|        |                              |
         |  Offer netwoork   |        |                              |
         |   configuration   |        |                              |
         |<------------------|        |                              |
   +-----|                   |        |                              |
   |Get  |                   |        |                              |
   |gate |                   |        |                              |
   |way  |                   |        |--------+                     |
   +---->|            I1     |        | Check  |                     |
         |--------------------------->|  HIT   |                     |
         |                   |        | in ACL |                     |
         |                   |        |<-------+                     |
         |       R1 (REG_INFO)        |                              |
         |<---------------------------|                              |
         |                   |        |                              |
         |                   |        |--------+                     |
         |     I2 (REG_REQUEST)       | Check  |                     |
         |--------------------------->|  HIT   |                     |
         |                   |        | in ACL |                     |
         |                   |        |<-------+                     |
         |     R2 (REG_RESPONSE)      |                              |
         |<---------------------------|                              |
         |                   |        |                              |
         |                   |        |--------+                     |
         |     Plain IP(SAVAH opt)    | Check  |                     |
         |--------------------------->| source |                     |
         |                   |        |   IP   |                     |
         |                   |        |<-------+                     |
         |                   |        |    Plain IP (no SAVAH opt)   |
         |                   |        |----------------------------->|
         |                   |        |                              |
         |                   |        |                              |
         |                   |        |    Plain IP (no SAVAH opt)   |
         |<----------------------------------------------------------|
         |                   |        |                              |
         |                   |        |                              |

                                 Figure 1




Kuptsov, et al.         Expires September 7, 2009               [Page 4]


Internet-Draft                    SAVAH                       March 2009


   SAVAH is targeted to solve the source address validation problem in
   the edge router of the local network, serving as a default gateway.
   Because of that, SAVAH architecture is composed of two main
   components:

   o  SAVAH enabled client, which is a combination of a HIP daemon and a
      firewall in a client mode supporting SAVAH extension

   o  SAVAH enabled router running the HIP daemon and the firewall but
      in server mode

   DHCP server can be considered a third component in our architecture.
   Its main role in the network is to offer particular configuration for
   SAVAH aware hosts.  For instance, DHCP can provide the default
   gateway IP address as well as HIT of the SAVAH router.  Availability
   and proper configuration of DHCP server can help to solve the problem
   of opportunistic mode that is being discussed later in this section.
   However, we consider DHCP as an optional component in the network
   topology.  SAVAH aware clients can be configured manually, meaning
   that the IP address and the HIT of the SAVAH router can be setup by a
   system administrator prior to any communication.  However, manual
   configuration can be a tedious task in a large scale network.  As a
   third option, if non of the advised is accessible in the local
   network, the SAVAH enabled client can try to discover the SAVAH
   router using the opportunistic mode.  The message sequence diagram
   for SAVAH registration and further authentication process is shown in
   Figure 1.  As discussed previously it can involve three entities in
   the local network to perform the source address validation: the SAVAH
   client, the SAVAH router and the DHCP server (optionally).  The
   receiver on Figure 1 is playing the role of a legacy peer, i.e., it
   may or may not support HIP.  Of course, if both communicating peers
   support HIP protocol the whole scenario requires only normal HIP-
   enabled firewall to filter the traffic based on HITs.

2.1.  SAVAH router discovery and registration

   Successful passing of the address validation procedure on the first-
   hop router requires a client to register.  This is completed through
   HIP registration extension RFC5203 [RFC5203].  Since SAVAH router is
   the first-hop router, it should be placed on the edge of the local
   network and serve as a default gateway.  If the default gateway and
   the SAVAH router are not placed physically on the same node it
   becomes meaningless, because all network traffic flowing through the
   SAVAH-unaware router would not contain SAVAH option and would be
   discarded.  If DHCP server does not offer a HIT of the SAVAH router
   during the address assignment phase, then the SAVAH client is obliged
   to discover the presence of the SAVAH service automatically.
   Otherwise, the client is aware of the HIT and the IP address of the



Kuptsov, et al.         Expires September 7, 2009               [Page 5]


Internet-Draft                    SAVAH                       March 2009


   SAVAH router and can register to the service directly.  It is also
   possible to preconfigure the client and specify the IP address and
   HIT of the default gateway.  Optionally, the presence of a SAVAH-
   unaware DHCP means that the client will obtain only the IP address of
   the default gateway.  No prior knowledge of the SAVAH router's HIT
   forces the client to discover the service using the HIP opportunistic
   mode [I-D.lindqvist-hip-opportunistic] and a set of standardized
   procedures for HIP service registration as described in RFC5203
   [RFC5203].The drawback of such broadcasting is that in the
   opportunistic mode the client is unaware of the HIT of SAVAH router
   and any node can thus pretend to be a valid router.  This reminds a
   similar problem with SSH, when connecting to an unknown hosts.
   Hence, the opportunistic mode should be used only in a trusted
   environment.  To trigger a registration in opportunistic mode, the
   SAVAH client requests from the system the default gateway IP address
   and sends an I1 packet with the destination HIT as a hashed source IP
   address.  On the other side, the default gateway running SAVAH in a
   server mode responds with an R1 packet containing an offer for
   available services in REG_INFO parameter.  Upon receiving the R1
   packet the client chooses the supported services and responds with an
   I2 packet containing a REG_REQUEST parameter to SAVAH server.  If REG
   INFO parameter does not contain the SAVAH service offer, the client
   completes base exchange normally and afterward falls to a normal
   communication, i.e.  SAVAH mode is not supported in this network.
   Finally, depending on the setup of the SAVAH router, it either grants
   or denies the service to client in a R2 packet in a REG_RESPONSE or
   REG_FAILED parameter correspondingly.  Receiving REG_FAILED parameter
   in an R2 message during the base exchange or experiencing a timeout
   in a I1 state means that either the default gateway does not support
   SAVAH extension or that HIP daemon with SAVAH extension is not
   running at all.  This situation should indicate to the SAVAH client
   to fallback to a normal communication, i.e., the packets that would
   be forwarded through the default gateway will not contain any
   authentic information.  As an opposite result, if the SAVAH router
   grants the service to the registering client, both parties will
   posses a shared secret key.

2.2.  Source address validation

   For performance issues, the keys that are used for authentication
   (i.e., HMAC keys) in IPSec were selected to authenticate the source
   addresses.  Depending on a setup, symmetric cryptography can be
   selected as well.  Filtering based on HITs can be done to ensure that
   the peer trying to register to the SAVAH service is legitimate.  This
   filtering can enforce to either grant or deny the SAVAH service to
   the registrars.  The grounds for such a decision can be rules
   specified in the HIP-enabled firewall.  By default, all packets with
   unknown identifier are dropped.  After completion of the HIP base



Kuptsov, et al.         Expires September 7, 2009               [Page 6]


Internet-Draft                    SAVAH                       March 2009


   exchange, the SAVAH router adds the source IP address of the host to
   a database.  This works if no record with such IP address already
   present in the database.  If a record with such IP address already
   exists, it is likely that the host is trying to spoof someone else
   address and the packet should be dropped nor state is added.
   Moreover this incident can be logged and reported for further
   analysis.  If the host experiences an address change, then the record
   is replaced with a new IP address.  To ensure the validity of the
   host, HIP UPDATE packet has to be received and handled properly.
   This will guarantee that the host indeed who it is claiming to be.
   The record should be removed from the database upon a timeout or when
   the host removes a security association (e.g., HIP CLOSE packet is
   received from the corresponding host).  To ensure that the client is
   alive, SAVAH router can also send heartbeats to the client, without
   waiting for the timeout.  After the secret keys were established by
   means of the HIP base exchange, the SAVAH client may communicate with
   the nodes outside of the local network by including an authenticated
   source IP address in each packet.  Current implementation has two
   options to deliver the authenticated hash value to the router.  First
   approach is to replace the original source IP address of each packet
   with truncated result obtained from HMAC(key | {P}) operation, where
   {P} is the packet to be transmitted.  We have chosen the packet value
   as a feed to HMAC function to introduce simple protect mechanism from
   replay attacks.  This approach has some drawbacks.  First of all, for
   IPv4 networks the size of authentication value will be only 32 bits.
   Secondly, that would decrease the performance since additional
   address translation would be required on the router.  Finally, that
   method will require additional changes to the router to recognize
   locally routed traffic.  A different way to carry the authenticated
   source IP address to SAVAH router is to store it in an IP option.
   Since the SAVAH router is the first-hop router and all SAVAH related
   options are striped out on the forward direction, this ensures that
   no modifications are required for other routers on the path.  Placing
   the authentication value in the IP option can have certain
   advantages.  First of all, this approach slightly optimizes the
   performance of the architecture.  Secondly, stronger security can be
   achieved by increasing the length of the authentication value.  We
   suggest to keep this length within wise bounds, since it affects the
   size of the actual payload.  To authenticate the packet source
   address, the following algorithm is used.  On the router side, each
   packet in forward direction is searched for the SAVAH IP option.  If
   found, the router compares the value of the option against truncated
   128-bit result from HMAC(key | {P}) operation, where {P} is the
   packet to be forwarded.  If matches, the SAVAH option is striped out
   and the packet is re-injected to the network.  If not, the pinhole is
   searched for a given source and destination IP addresses.  If the
   pinhole is found, the packet is said to be an inbound packet for
   previously authenticated outbound communication.  Finally, if both



Kuptsov, et al.         Expires September 7, 2009               [Page 7]


Internet-Draft                    SAVAH                       March 2009


   are failed the packet is dropped.  If the tunneling approach is used,
   then the authentication succeeds if the SAVAH router can successfully
   decrypt the ESP packet and resend encapsulated in ESP original packet
   to its final destination.  Unlike the lightweight approach for
   inbound traffic, the SAVAH router in a tunnel mode should properly
   encrypt and tunnel the packet to the corresponding mobile node.

2.3.  SAVAH tunneling mode

   This section describes how SAVAH operates in tunneling mode.  The
   major difference from the lightweight SAVHA mode (SAVAH protocol
   overview section (Section 2)) is that all traffic leaving the local
   host is encapsulated in ESP packets and forwarded to SAVAH router.

      Client               DHCP    Router                          Peer
         |  Request network  |          |                              |
         |   configuration   |          |                              |
         |------------------>|          |                              |
         |  Offer netwoork   |          |                              |
         |   configuration   |          |                              |
         |<------------------|          |                              |
   +-----|                   |          |                              |
   |Get  |                   |          |                              |
   |gate |                   |          |                              |
   |way  |                   |          |---------+                    |
   +---->|            I1     |          |  Check  |                    |
         |----------------------------->|  HIT    |                    |
         |                   |          | in ACL  |                    |
         |                   |          |<--------+                    |
         |       R1 (REG_INFO)          |                              |
         |<-----------------------------|                              |
         |                   |          |                              |
         |                   |          |--------+                     |
         |     I2 (REG_REQUEST)         | Check  |                     |
         |----------------------------->|  HIT   |                     |
         |                   |          | in ACL |                     |
         |                   |          |<-------+                     |
         |     R2 (REG_RESPONSE)        |                              |
         |<-----------------------------|                              |
         |                   |          |                              |
         |                   |          |--------+                     |
         | ESP tunneld IP traffic       | Check  |                     |
         |----------------------------->| source |                     |
         |                   |          |   IP   |                     |
         |                   |          | Decrypt|                     |
         |                   |          |   ESP  |                     |
         |                   |          |<-------+                     |
         |                   |          |                              |



Kuptsov, et al.         Expires September 7, 2009               [Page 8]


Internet-Draft                    SAVAH                       March 2009


         |                   |          |                              |
         |                   |          |    Plain IP (non encypted)   |
         |                   |          |----------------------------->|
         |                   |          |                              |
         |                   |          |                              |
         |                   |          |    Plain IP (non encrypted)  |
         |                   |          |<-----------------------------|
         |                   |          |                              |
         |                   | +--------+                              |
         |                   | |Check   |                              |
         |                   | |pinhole |                              |
         |                   | |Encrypt |                              |
         |                   | |traffic |                              |
         |                   | +------->|                              |
         |                   |          |                              |
         |    ESP tunneled IP traffic   |                              |
         |<-----------------------------|                              |
         |                   |          |                              |

                                 Figure 2

   The registration and source address validation mechanisms are the
   same as in lightweight SAVAH mode.

   Once the encrypted packet arrives on the SAVAH router it decrypts the
   packet validates the source IP address and forwards the encapsulated
   original packet to the destination host.

   Upon the arrival of the packet from the Internet on the SAVAH router,
   its task to check if the pinhole exists.  If there was previous
   communication the SAVAH router encrypts the packet (in similar way it
   is done on the SAVAH client) and forwards ESP encapsulated packet to
   the corresponding SAVAH client.


3.  Packet format

   This section describes the format of the IP options that are used to
   carry authentication data.

   For IPv4 protocol the format of SAVAH option is as follows:










Kuptsov, et al.         Expires September 7, 2009               [Page 9]


Internet-Draft                    SAVAH                       March 2009


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Option type |  Option Len   |                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 +
   |                                                               |
   +                                                               +
   |                   Encrypted source IP address                 |
   +                                                               +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |          Padding              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 3

   o  Option Type (value 158) is the field that describes SAVAH option,
      and concatenation of the following bit values:

      *  First highest bit is 1 indicating to copy this option to every
         packet

      *  Next 2 bits (Option Class) is 00 meaning that this is control
         option

      *  The last 5 bits are 11110 which signal the experimental purpose
         of the option as assigned in RFC 4727 [RFC4727]

   o  Encrypted source IP address is the truncated 128 bit length result
      from operation HMAC(key|IP address), where key is the pre-shared
      secret key, and IP address is the source address of the packet

   o  Padding is zero fill up to the multiplicative of 32 RFC 791
      [RFC0791]

   For IPv6 protocol the format of SAVAH option is as follows:















Kuptsov, et al.         Expires September 7, 2009              [Page 10]


Internet-Draft                    SAVAH                       March 2009


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  Hdr Ext Len  |  Option type  |  Option Len   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                   Encrypted source IP address                 |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Padding Type | Padding Len   |          Padding              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 4

   o  Next Header field is selected to be Destination Option as
      described in RFC 2460 [RFC2460]

   o  Hdr Ext Len is the length of option 8-octet units, not including
      the first 8 octets.  For SAVAH this is equal to 2

   o  Option Type is the field that describes the actual data in the
      option, for Destination Option there can be multiple such TVL
      encoded fields.  Here the Option type is encoded as follows:

      *  Highest 2 bits are 00 indicating to skip the option if it is
         not recognized by the router

      *  Next bit is 0 meaning Option Data does not change en-route

      *  The last 5 bits are 11110 as assigned in RFC 4727 [RFC4727] for
         experiments

   o  Encrypted source IP address is the truncated 128 bit length result
      from operation HMAC(key|IP address), where key is the pre-shared
      secret key, and IP address is the source address of the packet

   o  Padding is of type PadN as described in RFC 2460 [RFC2460]

   o  Padding Len is the length of actual padding excluding first 2
      octets, and in SAVAH case equal to 2

   o  Padding is the 2 zero filled octets

   IPv4/IPv6 packet structure for SAVAH in tunnel mode:



Kuptsov, et al.         Expires September 7, 2009              [Page 11]


Internet-Draft                    SAVAH                       March 2009


            BEFORE APPLYING ESP
   -----------------------------
   | Outer IP hdr |  Payload   |
   |              |            |
   -----------------------------

                                 Figure 5

   o  Outer IP hdr is the IPv4 or IPv6 header containing the source IP
      address of the local host and the destination of the host in the
      Internet, or host in the local sub-network.

   o  Payload is the data containing the upper layer protocol PDU (such
      as TCP, UDP, SCTP, etc.) and the user payload.


           AFTER APPLYING ESP
   ------------------------------------------------------------------
   | SAVAH IP hdr    |     |              |         |  ESP    | ESP |
   | (any options)   | ESP | Outer IP Hdr | Payload | Trailer | ICV |
   ------------------------------------------------------------------
                           |<----- encryption ----->|
                     |<--------- integrity -------->|


                                 Figure 6

   o  Gateway IP hdr is the IPv4 or IPv6 header containing the source IP
      address of the local host and the destination IP address of the
      SAVAH router in given local sub-network.

   o  ESP is the Encapsulated Security Payload in BEET mode.

   o  Outer IP header is the IPv4 or IPv6 header containing the source
      address of the localhost and the destination address of the host
      in the Internet, or of the host in the local sub-network.  It is
      different from ESP BEET mode Outer address, and more reflects the
      meaning of the Outer IP address of the ESP tunnel mode.


4.  Security Considerations

   Using opportunistic mode in HIP should be considered as a security
   risk in untrusted environment, due to the fact that the router's HIT
   is not known before the registration.  This gives a possibility to an
   attacker to hijack the HIP I1 packet and pretend to be a SAVAH router
   by sending the R1 packet to the client.




Kuptsov, et al.         Expires September 7, 2009              [Page 12]


Internet-Draft                    SAVAH                       March 2009


   Using tunneling approach a single SAVAH router may become a single
   point of failure as well as a bottleneck in the network
   communication.  For that reason it is recommended to use load
   balancing between multiple SAVAH router and forward the traffic from
   the client to the Internet through several (depending on the network
   size) SAVAH routers.


5.  Credits

   The following people have provided thoughtful and helpful discussions
   and/or suggestions that have helped to improve this document:

   o  Miika Komu


6.  Normative References

   [I-D.bi-savi-csa]
              Bi, J., Wu, J., and G. Yao, "A CGA based Source Address
              Authorization and Authentication (CSA) Mechanism  for
              First IPv6 Layer-3 Hop", draft-bi-savi-csa-00 (work in
              progress), July 2008.

   [I-D.lindqvist-hip-opportunistic]
              Lindqvist, J., "Establishing Host Identity Protocol
              Opportunistic Mode with TCP Option",
              draft-lindqvist-hip-opportunistic-01 (work in progress),
              March 2006.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
              ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.

   [RFC5203]  Laganier, J., Koponen, T., and L. Eggert, "Host Identity
              Protocol (HIP) Registration Extension", RFC 5203,
              April 2008.

   [RFC5210]  Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams,
              "A Source Address Validation Architecture (SAVA) Testbed



Kuptsov, et al.         Expires September 7, 2009              [Page 13]


Internet-Draft                    SAVAH                       March 2009


              and Deployment Experience", RFC 5210, June 2008.


Authors' Addresses

   Dmitriy Kuptsov
   Helsinki Institute for Information Technology
   PO. Box 9800
   TKK  FI-02015
   Finland

   Phone: +358 50 301 2613
   Email: dmitriy.kuptsov@hiit.fi


   Andrei Gurtov
   Helsinki Institute for Information Technology
   PO. Box 9800
   TKK  FI-02015
   Finland

   Phone:
   Email: gurtov@hiit.fi


   Jun Bi
   Tsinghua Univeristy
   Beijing,
   China

   Phone:
   Email:



















Kuptsov, et al.         Expires September 7, 2009              [Page 14]


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