A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration (SSAS)
draft-rafiee-6man-ssas-00

IPv6 maintenance Working Group (6man)                         H. Rafiee
INTERNET-DRAFT                                 Hasso Plattner Institute
Updates RFC 3971 , 3972, 4941 (if approved)                   C. Meinel
Intended status: Proposed Standard             Hasso Plattner Institute
Expires: July 2, 2013                                    January 2, 2013

A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration 
                                (SSAS) 
                     <draft-rafiee-6man-ssas-00.txt>

Abstract

   The default method for IPv6 address generation uses two unique 
   manufacturer IDs that are assigned by the IEEE Standards Association 
   [1] (section 2.5.1 RFC-4291) [RFC4291]. This means that a node will 
   always have the same Interface ID (IID) whenever it connects to a new 
   network. Because the node's IP address does not change, the node is 
   vulnerable to privacy related attacks. To address this issue, there 
   are currently two mechanisms in use to randomize the IID, 
   Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy 
   Extension [RFC4941]. The problem with the former approach is the 
   computational cost involved for the IID generation. The problem with 
   the latter approach is that it lacks security. This document offers a 
   new algorithm for use in the generation of the IID while, at the same 
   time, securing the node against some types of attack, such as IP 
   spoofing. These attacks are prevented with the addition of a 
   signature to the Neighbor Discovery messages (NDP). 

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 June 21, 2013. 

   

Rafiee, et al.         Expires July 2, 2013                     [Page 1]
INTERNET DRAFT       SSAS for Autoconfiguration          January 2, 2013

Copyright Notice

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

Table of Contents

   1.  Introduction   . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Replay attack  . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Denial of Service (DoS) attacks  . . . . . . . . . . . . .  4
     3.3.  Spoofed Redirect Message   . . . . . . . . . . . . . . . .  5
   4.  Algorithm Overview   . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Interface ID (IID) Generation  . . . . . . . . . . . . . .  5
     4.2.  Signature Generation   . . . . . . . . . . . . . . . . . .  7
     4.3.  Generation of NDP Messages   . . . . . . . . . . . . . . .  8
       4.3.1.  SSAS signature data field  . . . . . . . . . . . . . .  8
     4.4.  SSAS verification process  . . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative  . . . . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13

Rafiee, et al.         Expires July 2, 2013                     [Page 2]
INTERNET DRAFT       SSAS for Autoconfiguration          January 2, 2013

1.  Introduction 

   IPv6 addresses consist of two parts; the subnet prefix, which is the 
   64 leftmost bits of the IPv6 address, and the Interface ID (IID), 
   which is the 64 rightmost bits of IPv6 address. The IEEE Standards 
   Association [1] (section 2.5.1 RFC-4291) [RFC4291] offered a standard 
   for the generation of the IPv6 Interface IDs (IID). They are 
   generated by the concatenation of an Extended Unique Identifier 
   (EUI-64) with an Organizationally Unique Identifier (OUI), both of 
   which are assigned by the IEEE Registration Authority (IEEE RA). For 
   example, if a manufacturer's OUI-36 hexadecimal value is 
   00-5A-D1-02-3, and the manufacture hexadecimal value for the 
   extension identifier for a given component is 4-42-61-71, then the 
   EUI-64 value generated from these two numbers will be 
   00-5A-D1-02-34-42-61-71. There are two mechanisms used to randomize 
   the IID; CGA [RFC3972] and Privacy Extension [RFC4941]. In this 
   document we discuss the problem inherent with using the current 
   mechanisms and then we propose our solution to the problem which is 
   to randomize the IID, while, at the same time, providing security to 
   Neighbor Discovery Protocol (NDP) messages. 

2.  Conventions used in this document 

   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 this document, these words will appear with that interpretation 
   only when in ALL CAPS. Lower case uses of these words are not to be 
   interpreted as carrying RFC-2119 significance. 

   This convention aids reviewers in quickly identifying or finding the 
   explicit compliance requirements of this RFC. 

   In this document whenever this sign || is used, it means the 
   concatenation of the values on either side of this sign. 

3.  Problem Statement 

   The drawback to the IEEE Standards Association approach for the 
   generation of the IID is one of privacy. The node will generate the 
   same IID when it joins a new network. It will therefore be easy for 
   an attacker to track the node on this network. 

   The main problem with the privacy extension mechanism, when using the 
   first approach, as explained in section 3.2.1 RFC-4941 [RFC4941] , 
   i.e., using stable storage, is the lack of a provision for use of a 

Rafiee, et al.         Expires July 2, 2013                     [Page 3]
INTERNET DRAFT       SSAS for Autoconfiguration          January 2, 2013

   security mechanism. A Privacy extension can prevent attacks related 
   to privacy issues, but it cannot prevent attacks related to security 
   issues. For instance, it cannot prevent IP spoofing attacks and it 
   cannot prove the address ownership of a node. If one wants to use a 
   secure method, with the privacy extension, then one needs to use CGA. 
   The problem with using CGA is the complexity of the CGA algorithm and 
   in the computational overhead necessary to compute it when a higher 
   sec value is used. 

   While we explain the problem with the other mechanisms, we propose 
   that the use of the SSAS algorithm, along with the SSAS signature, 
   will provide a node the protection it needs against IP spoofing and 
   spoofing types of attack. 

   The following sections detail some of these types of attack. 

3.1.  Replay attack 

   In this type of attack, an attacker might sniff the Neighbor 
   Discovery Protocol enabled networks (NDP) messages and try to copy 
   the legitimate signature and public key to his NDP message and then 
   send this to the sender. But by using the SSAS algorithm, this is 
   prevented with the addition of a timestamp to the NDP message and 
   also with inclusion of this timestamp in the signature. The use of 
   the timestamp works because the timestamp is not valid for more than 
   10 minutes (that is for clock skews). 

   IP spoofing. This is a well-known type of attack in NDP. This type of 
   attack is used to attack the Duplicate Address Detection process. In 
   this attack, when a node joins the network and generates a new IP 
   address, the node sends a Neighbor Solicitation (NS) message to check 
   for address collisions in the network. The attacker, in this 
   scenario, spoofs the IP address and responds back to the node with a 
   Neighbor Advertisement (NA) message claiming ownership of this IP 
   address. The SSAS algorithm allows this node to verify other nodes in 
   the network. An attacker does not have the private key for this node, 
   which is needed to generate a SSAS signature, so the verification 
   process will fail. 

3.2.  Denial of Service (DoS) attacks 

   An attacker might send many NDP messages, using invalid signatures, 
   to the victim?s node which then forces the node to busy itself with 
   the verification process. To prevent this attack, a limit on the 
   number of messages that the node should verify, per minute, can be 
   set, and messages exceeding that count will be ignored. 

Rafiee, et al.         Expires July 2, 2013                     [Page 4]
INTERNET DRAFT       SSAS for Autoconfiguration          January 2, 2013

3.3.  Spoofed Redirect Message 

   Redirect messages, imitating the end host needing redirection, can be 
   sent from any router on the same broadcast segment. The attacker uses 
   the link-local address of the current first-hop router in order to 
   send a Redirect message to a legitimate node. Since that node 
   identifies the message as coming from its first hop router, by use of 
   the link-local address, it accepts the Redirect. The Redirect will 
   remain in effect as long as the attacker responds to the Neighbor 
   Unreachability Detection probes sent to the link-layer address. To 
   preclude this from occurring, the address ownership of the first-hop 
   router should be verified. The use of the SSAS verification process 
   will prevent such an attack. 

4.  Algorithm Overview 

   As explained earlier, one of the problems with the current IID 
   generation approach is the compute intensive processing needed for 
   the IID algorithm generation. Another concern is the lack of 
   security. Since, we assume that a node needs to generate and keep its 
   address for a short time, we tried to keep the IID generation process 
   to a minimum. We also tried to remain within the confines of NDP 
   protocol. 

4.1.  Interface ID (IID) Generation 

   To generate the IID, a node needs to execute the following steps. 

   1. Generate a 16 byte random number called modifier. 

   2. Generate a 1024-bit key pair (public/private key). These keys 
   SHOULD be stored in a safe place on a local hard disk and the path to 
   this data, and the validation time for these keys, SHOULD be saved in 
   a XML file. It is RECOMMENDED that the public key be generated, on 
   the fly, during the start-up phase of the algorithm generation. 

   Once a node generates key pairs, it can make use of these keys for a 
   short period of time. It is RECOMMENDED not to use the same keys for 
   more than 2 days in order to prevent the node from being tracked 
   through the use of its public keys. When time expires for the use of 
   these key pairs, the node should generate new key pairs and replace 
   the old one in the XML file. It SHOULD then use the new value for IP 
   address and signature generation. 

   3. Concatenate the modifier with the global subnet prefix obtained 
   from the Router Advertisement (RA) message, the timestamp and the 
   public key. The timestamp is a 64-bit unsigned integer field 
   containing a timestamp. The value indicates the number of seconds 
   since January 1, 1970, 00:00 UTC, by using a fixed point format. The 

Rafiee, et al.         Expires July 2, 2013                     [Page 5]
INTERNET DRAFT       SSAS for Autoconfiguration          January 2, 2013

   format of the timestamp data field is the same as that outlined in 
   section 5.3.1 RFC-3971 [RFC3971]. 

   R1=(modifier(16 bytes)||subnet prefix(8 bytes)||timestamp(8 
   bytes)||public key) 

   4. Execute SHA2 (256) on the result from step 3. 

   digest=SHA256(R1) 

   The use of SHA2 (256) is RECOMMENDED because the chances of finding a 
   collision are less than when using SHA1 and the generation time is 
   acceptable (in microseconds using a standard CPU). 

   5. Generate a random number between 0 and 20 and call it the start 
   index. This number is used as an index for the SHA2 array of bytes. 
   This value helps randomize the IID and to minimize the chance of a 
   collision in the network. The length of this number is one byte. 

   6. Take the 32 leftmost bits (starting at the start index) from the 
   resulting output from step 5 (SHA2 digest) and set bits u and g (bits 
   7 and 8) and call this the partial IID. 

   
   +-------------------------------------+
   |           |  partial IID  |         |
   |           |   (32 bits)   |         |
   +           +---------------+         +
   |             SHA2 digest             |
   |             (256 bits)              |
   +-------------------------------------+
    Figure  1  Partial Interface ID
 

   7. Obtain the second byte of the partial IID and call it the start 
   field pubkey. If the value of the start field pubkey is between 0 and 
   the size of public key length, in bytes, minus 4, use this number as 
   an index for the public key array of bytes. Otherwise set the start 
   field pubkey to 1. This value helps randomize the IID and minimize 
   the chance of a collision in the network. For example, if the second 
   byte of the partial IID is 110, then the start field pubkey value 
   will be 110. 

   
   +-------------------------------------+
   |           |     Pubkey    |         |
   |           |   (32 bits)   |         |
   +           +---------------+         +
   |             Public key              |
   |            (1024 bits)              |
   +-------------------------------------+
    Figure  2  Public key part of Interface ID
 

Rafiee, et al.         Expires July 2, 2013                     [Page 6]
INTERNET DRAFT       SSAS for Autoconfiguration          January 2, 2013

   8. Concatenate the partial IID with the four bytes from the public 
   key (starting at the start field pubkey) and call this the IID. 

   
   +-------------------+------------------+
   |   Partial IID     |     Pubkey       |
   |    (32 bits)      |   (32 bits)      |
   +-------------------+------------------+
    Figure  3  Interface ID
 

   9. Concatenate the IID with the local subnet prefix to set the local 
   IP address 

   10. Concatenate the IID with the router subnet prefix (Global subnet 
   prefix), obtained from the RA message, and set it as a tentative 
   global IP address. (This IP will be permanent after Duplicate Address 
   Detection (DAD) processing. (for more information about DAD refer to 
   section 4.3. ) 

4.2.  Signature Generation 

   The SSAS signature is added to NDP messages in order to protect them 
   from IP spoofing and spoofing types of attack. SSAS will prove 
   address ownership, as does the CGA generation algorithm, but with 
   fewer steps. To generate the SSAS signature, the node needs to 
   execute the following steps: 

   1. Concatenate the timestamp with the 16 byte public key (that starts 
   at the start field pubkey) (see figure 4) and the global IP address. 
   The start field pubkey is one of the numbers that was introduced in 
   step 7 of section 4.1. 

   2. Sign the resulting value from step 1, using the RSA private key, 
   and call the resulting output the SSAS signature. 

   
  +---------+----------+-----------------+-------------+
  |timestamp|Public key|Global IP Address|Other Options|
  |(8 bytes)|(16 bytes)|   (16 bytes)    |  (variable) |
  +---------+----------+-----------------+-------------+
    Figure  4 SSAS Signature
 

   If NDP messages contain other data that must be protected, such as 
   important routing information, this data SHOULD also be included in 
   the signature. The signature is designed for the inclusion of any 
   data needing protection. If there is no data that needs protection, 
   then the signature will only contain the timestamp, 16 byte public 
   key and Global IP address (Router subnet prefix plus IID). 

Rafiee, et al.         Expires July 2, 2013                     [Page 7]
INTERNET DRAFT       SSAS for Autoconfiguration          January 2, 2013

4.3.  Generation of NDP Messages 

   After a node generates its IP address, it should then process 
   Duplicate Address Detection in order to avoid address collisions in 
   the network. To do this, the node generates a Neighbor Solicitation 
   (NS) message. The format of a NS message is shown in figure 5. The 
   SSAS signature is added to the ICMPv6 options of NS messages. The 
   SSAS signature data field is an extended version of the standard 
   format of the RSA signature option of SEND [RFC3971]. The timestamp 
   option is the same as that used with SEND. In the SSAS signature, the 
   data field contains type, length, reserved, Other Len, pubkey len, 
   public key, SSAS signature, and padding. 

   
   +----------------+-------------+----------------------------+
   |   IPv6 Header  |ICMPv6 header|  ND message Specific Data  |
   | Next header= 58|             |         (variable)         |
   +--------------+-+-----------+-+----------------------------+
   |   Type = 13  |    length   |           Reserved           |
   |   (1 byte)   |   (1 byte)  |           (6 bytes)          |
   +--------------+-------------+------------------------------+
   |                       timestamp                           |
   |                                                           |
   +--------------+-------------+-------------+----------------+
   |   Type = 12  |    length   |   Reserved  |   Other Len    |
   |   (1 byte)   |   (1 byte)  |   (2 bytes) |    (1 byte)    |
   +--------------+-+-----------+-----+-------+----------------+
   | Subnet Prefix  |    Pubkey Len   |   Public Key in base64 |
   |   (8 byte)     |     (1 byte)    |        format          |
   +----------------+-----------------+------------------------+
   |                       Other Options                       |
   |                                                           |
   +-----------------------------------------------------------+
   |                      SSAS Signature                       |
   |                                                           |
   +-----------------------------------------------------------+
   |                       padding                             |
   |                                                           |
   +-----------------------------------------------------------+
   Figure 5  NDP Message Format with SSAS Signature Data Field

 

4.3.1.  SSAS signature data field 

   - Type: This option should be set to 12. 

Rafiee, et al.         Expires July 2, 2013                     [Page 8]
INTERNET DRAFT       SSAS for Autoconfiguration          January 2, 2013

   - Length: The length of the Signature Data field, including the Type, 
   Length, Reserved, pubkey Len, public key, Signature and padding, 
   should be a multiple of eight. 

   - Reserved: A 2 byte field reserved for future use. The value MUST be 
   initialized to zero by the sender, and MUST be ignored by the 
   receiver. 

   - Other Len: The length of other options in multiples of eight. The 
   length of this is 1 byte. 

   - Subnet Prefix: This is the router subnet prefix. 

   - PubKey Len. The length of the public key in multiples of eight. 

   - Public key. Base64 format of the public key 

   - Other Options. This variable-length field contains important data 
   that needs to be protected in the packet . The padding would be 
   added, as many bytes long as remain after the end of the field, if 
   the Other options is not a multiple of eight. 

   - Padding. This variable-length field contains padding, as many bytes 
   long as remain after the end of the signature, if the signature is 
   not a multiple of eight. 

   All NDP messages should contain the SSAS signature data field which 
   allows receivers to verify senders. If a node receives a solicited NA 
   message in response to its NS message showing that another node 
   claims to own this address, then, after a successful verification 
   process, this node increments the modifier by one and again repeats 
   steps 3 thru 8 of section 4.1 . If, for a second time, the node 
   receives the same claim, then it considers it an attack and will use 
   that IP address. 

4.4.  SSAS verification process 

   A node's verification process should start when it receives NDP 
   messages. 

   Following are the verification steps: 

   1. Obtain the timestamp from the NDP message and call this value t1. 

   2. Obtain the timestamp from the node's system, convert it to UTC, 
   and call this value t2. 

   3. If (t2- 600) < = t1 < = (t2 + 600) go to stop 4. Otherwise, the 
   message SHOULD be discarded without further processing. (10 minutes 
   (600 seconds) is used as a flexible way of handling network delays.) 

Rafiee, et al.         Expires July 2, 2013                     [Page 9]
INTERNET DRAFT       SSAS for Autoconfiguration          January 2, 2013

   4. Obtain the public key from the SSAS signature data field. 

   5. Compare this to its own public key. If it is not the same, go to 
   the next step. Otherwise, the message should be discarded without 
   further processing. 

   6. Obtain the second byte of the partial IID and call it the start 
   field pubkey. If the value of the start field pubkey is between 0 and 
   the size of public key length, in bytes, minus 4, use this number as 
   an index for the public key array of bytes. Otherwise set start field 
   pubkey to 1. 

   7. Obtain the IID from the sender?s source IP address. (64 rightmost 
   bits of the IPv6 address) 

   8. Compare the 32 leftmost bits, starting at the start field pubkey 
   of the public key, to the 32 rightmost bits of the IID of the 
   sender?s IP address. If they are the same, go to the next step. 
   Otherwise, the message should be discarded without further processing 

   9. Obtain the subnet prefix from the SSAS signature data field. 

   10. Concatenate the timestamp with the 16 bytes of the public key, 
   (starting from start field pubkey), the subnet prefix, the sender?s 
   IID, and other options (if any) and call this entity the plain 
   message. 

   11. Obtain the SSAS signature from the SSAS signature data field. 

   12. Verify the Signature using the public key, and then enter the 
   plain message and the SSAS signature as an input to the verification 
   function. If the verification process is successful, process the 
   message. Otherwise, the message should be discarded without further 
   processing. 

5.  Security Considerations

   As a security consideration what one might ask is what are the odds 
   of an attacker being able to generate a public key having four 
   sequential bytes the same as the last rightmost 32 bits of the IID? 
   If he could, he could then generate the signature using his own 
   private key and thus break the SSAS. 

Rafiee, et al.         Expires July 2, 2013                    [Page 10]
INTERNET DRAFT       SSAS for Autoconfiguration          January 2, 2013

   Mathematically it has been shown that the probability of matching 32 
   bits in the public key against 32 bits in the IID is about 
   pow(1/2,32) where pow is the power function, 2 is a base and 32 is a 
   exponent. Since it is RECOMMENDED to use a public key and IP address 
   lifetime of a maximum of 2 days, the probability of an attacker 
   finding the same value is 0.00016, a very small value. This shows the 
   strength of this algorithm against brute force attacks while, at the 
   same time, by using the signature and finding a binding between the 
   IP address and the public key, it provides proof of address ownership 
   at a speed that is about 600 times faster than that of the CGA 
   algorithm. (based on the implementation results, the average time to 
   generate SSAS is 882.77 microseconds). 

   Another consideration concerns Routers wanting to use this algorithm 
   in place of CGA. As explained in RFC SEND, for routers, the use of a 
   Trusted Authority is RECOMMENDED along with verifying router 
   certificates using these third parties. This will prevent a node from 
   claiming to be a router. 

   

   

6.  IANA Considerations

   This document defines a new algorithm for the generation of an 
   Interface ID in IPv6 networks. 

7.  Conclusions

   Privacy has become a very important issue in recent years. A solution 
   for preventing a node from being tracked by an attacker is to change 
   the node's IP address frequently and by generating a random IID each 
   time a node wants to generate a new IP address. There are two 
   solutions available for randomizing the IID; CGA and Privacy 
   Extension. The former algorithm is compute intensive and the latter 
   algorithm is lacking in security. This document introduced a new 
   algorithm as a solution for providing privacy by randomizing the IID 
   and for providing security with the addition of a SSAS signature to 
   the NDP message and finding a binding between the public key and the 
   IP address. Our experimental results show a definite improvement in 
   the computation time for the SSAS algorithm as compared to that for 
   the CGA algorithm. We also note that the probability of having 
   collisions with IP addresses, when using the SHA2 digest and the 
   public key, with a randomized 62 bit selection, approximates 
   pow(1/2,62) where pow is the power function, 2 is a base and 62 is a 
   exponent (u and g bits are ignored) . Moreover, the probability of an 
   attacker finding the public key which matches 32 rightmost bits of 
   the IID within 2 days approximates 0.00016. This means this algorithm 

Rafiee, et al.         Expires July 2, 2013                    [Page 11]
INTERNET DRAFT       SSAS for Autoconfiguration          January 2, 2013

   is secure enough for wide usage. 

8.  References

8.1.  Normative References 

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

   [RFC4291] Hinden, R., Deering, S., "IP Version 6 Addressing 
             Architecture," RFC 4291, February 2006. 

   [RFC3972] Aura, T., "Cryptographically Generated Addresses 
             (CGA)," RFC 3972, March 2005. 

   [RFC4941] Narten, T., Draves, R., Krishnan, S., "Privacy 
             Extensions for Stateless Address Autoconfiguration in 
             IPv6", RFC 4941, September 2007. 

   [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, 
             "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 

8.2.  Informative References 

   [1] IEEE Standards Association, 
       http://standards.ieee.org/develop/regauth/tut/eui64.pdf, 2012 

Rafiee, et al.         Expires July 2, 2013                    [Page 12]
INTERNET DRAFT       SSAS for Autoconfiguration          January 2, 2013

Authors' Addresses

      Hosnieh Rafiee
      Hasso-Plattner-Institute
      Prof.-Dr.-Helmert-Str. 2-3
      Potsdam, Germany
      Phone: +49 (0)331-5509-546
      Email: ietf@rozanak.com

      Dr. Christoph Meinel
      (Professor)
      Hasso-Plattner-Institute
      Prof.-Dr.-Helmert-Str. 2-3
      Potsdam, Germany
      Email: meinel@hpi.uni-potsdam.de

Rafiee, et al.         Expires July 2, 2013                    [Page 13]