IETF Securing Neighbor Discovery WG                      Tuomas Aura
INTERNET DRAFT                                    Microsoft Research
Expires August 2003                                    February 2003

            Cryptographically Generated Addresses (CGA)
                       draft-aura-cga-00.txt

Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. 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.

Abstract

   Cryptographically generated addresses (CGA) are IPv6 addresses
   where the interface identifier is generated by hashing the address
   owner's public key. The address owner can then use the
   corresponding private key to assert address ownership and to sign
   messages sent from the address without any additional security
   infrastructure. This document describes a generic CGA format that
   can be used in multiple applications.
















Aura                  Expires August 24, 2003              [Page 1]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003

Table of Contents

Status of This Memo...............................................1
Abstract..........................................................1
Table of Contents.................................................2
1. Introduction...................................................3
2. The CGA Address Format.........................................4
3. The CGA Certificate and the Hash Values........................5
4. CGA Generation.................................................6
5. CGA Verification...............................................8
6. Security Considerations.......................................10
Acknowledgments..................................................12
Intellectual Property Statement..................................12
References.......................................................13
Authors' Addresses...............................................14





































Aura                  Expires August 24, 2003              [Page 2]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003

1. Introduction

   This document specifies how to create IPv6 addresses from the
   cryptographic hash of a public key (and auxiliary parameters).
   Public-key signatures can then be used for authenticating messages
   from the address owner. The main advantage of the CGA-based
   authentication is that additional security infrastructure, such as
   a PKI or TTP, is not needed. Potential applications include Mobile
   IPv6 binding update authentication (e.g. as a part of the CAM
   protocol [OR01]), proof of address ownership in secure neighbor
   discovery  and duplicate address detection [AAK+02], and key
   exchange for opportunistic IPSec encryption and authentication.

   The address format defined in this document differs from previous
   proposals [OR01][Nik01][MC02] at least in the following respects:

    (1)  Two hash values are computed instead of one. The first hash
         value (Hash1) is used to produce the Interface Identifier
         (i.e. rightmost 64 bits) of the address. The purpose of the
         second hash (Hash2) is to artificially increase that
         computational complexity of generating new addresses and,
         consequently, the cost of brute-force attacks. This allows
         the address owner to select levels of security above the 62-
         bit limit of CAM.

    (2)  The Routing Prefix (i.e. leftmost 64 bits) of the address is
         included in the first hash input, which makes some brute-
         force attacks against global-scope addresses more expensive
         because the attacker must do a separate brute-force search
         for each address prefix. However, we take care not to make
         mobility more expensive for the address owner. When the
         Routing Prefix changes, the second hash value can be reused,
         thus avoiding the expensive brute-force part of address
         generation.

    (3)  The input to both hash functions is formatted as (parts of)
         a self-signed X.509 v3 certificate. This has several
         advantages. First, a self-signed certificate is a standard
         format for storing and transferring public keys in Internet
         protocols. Second, the signature on the certificate proves
         that the public-key owner wants to use the IPv6 address.
         Third, future protocols may bind arbitrary security-critical
         information (other than the address owner's public key) to
         the IPv6 address by defining a new type of certificate
         extension for that purpose. Fourth, the use of X.509 v3
         certificates makes it easy to use CGA-based and PKI-based
         address authentication side by side in the same protocols.
         Some protocols, however, may need to save octets and
         transfer only the public key and other absolutely necessary


Aura                  Expires August 24, 2003              [Page 3]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003

         parameters, rather than a full self-signed certificate. An
         optimized parameter format is defined for this purpose.

   In order to verify the address owner's signatures, one needs to
   have the address itself and the associated self-signed certificate,
   which contains the public key. The address format and certificate
   format are defined in Sections 2 and 3. The detailed algorithms for
   generating addresses and for verifying them are given in Sections 4
   and 5. Finally, Section 6 discusses security of the technique.

2. The CGA Address Format

   The leftmost 64 bits of the 128-bit IPv6 Address form the Routing
   Prefix. The rightmost 64 bits of the address are called the
   Interface Identifier.

   Cryptographically generated addresses also have a security
   parameter (Sec), which determines the level of security. The
   security parameter is a 3-bit unsigned integer encoded in the three
   rightmost bits of the 128-bit IPv6 address.

                           Sec = Address & 7

   The address is associated with a self-signed X.509 v3 certificate,
   which contains the address owner's public key. Two hash values
   Hash1 and Hash2 are computed from parts of the certificate. The
   format of the certificate and the inputs to the hash functions are
   defined in Section 3.

   A cryptographically generated address (CGA) is defined as an IPv6
   address where the 12*Sec leftmost bits of the second hash value
   Hash2 are zero, and the rightmost 64 bits of the first hash value
   Hash1 equal the Interface Identifier of the address. The three
   rightmost bits of the address, which encode the security parameter
   Sec, and the universal and group bits are ignored in the
   comparison. The latter two bits must both be one. [Alternatively,
   we can stick with U=1, G=0. That would make it difficult to use
   CGA-based authentication side by side with weaker protocols.]

   The above definition can be stated in terms of the following three
   bit masks (Mask1, Mask2, Mask3):

     Mask1 = 0x00000000000000000000000000000000  if Sec=0,
             0xfff00000000000000000000000000000  if Sec=1,
             0xffffff00000000000000000000000000  if Sec=2,
             0xfffffffff00000000000000000000000  if Sec=3
             0xffffffffffff00000000000000000000  if Sec=4,
             0xfffffffffffffff00000000000000000  if Sec=5,



Aura                  Expires August 24, 2003              [Page 4]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003

             0xffffffffffffffffff00000000000000  if Sec=6, and
             0xfffffffffffffffffffff00000000000  if Sec=7

     Mask2 = 0x00000000000000000300000000000000

     Mask3 = 0x0000000000000000fffffffffffffff8

   A cryptographically generated address is an IPv6 address for which
   the following are true:

            (Hash1 & Mask3) | Mask2  ==  Address & Mask3
                        Hash2 & Mask1 == 0

3. The CGA Certificate and the Hash Values

   Each CGA address is associated with a self-signed X.509 v3
   certificate [HFPS02][ITU97]. The subjectPublicKeyInfo data value in
   the certificate is the address owner's public key. A certificate
   extension contains the following parameters: a 12-octet Modifier,
   the 8-octet Routing Prefix of the address, and Collision Count,
   which can get values 0, 1 and 2. The extnID field in the extension
   has the following value:

                cgaExtnID = { 1 3 6 1 4 1 311 TBD }

   The critical field in the extension MAY be set to false or true,
   depending on whether the certificate has other uses than CGA-based
   authentication. The extnValue field in the extension contains a
   DER-encoded data value of the following type:

                CGAParameters ::= SEQUENCE {
                  modifier       OCTET STRING (SIZE 12),
                  routingPrefix  OCTET STRING (SIZE 8),
                  collisionCount INTEGER (0..2) }

   Two 128-bit hash values Hash1 and Hash2 are computed with the MD5
   algorithm from parts of the certificate. The input to Hash1 is the
   concatenation of the DER-encoded subjectPublicKeyInfo and
   CGAParameters data values. The input to Hash2 is the concatenation
   of the DER-encoded subjectPublicKeyInfo and modifier data values.

   As an alternative to the certificate, an optimized parameter format
   MAY be used. The optimized format is simply the concatenation of
   the subjectPublicKeyInfo and CGAParameters data values. Security
   protocols that use CGA addresses MUST specify whether they use the
   certificate format or the optimized parameter format. The same
   address MAY be used in both types of protocols.




Aura                  Expires August 24, 2003              [Page 5]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003

   Note 1: The DER encoding of the CGAParameters data value is 29
   octets long and has the following (hexadecimal) format: 30 1d 04 0c
   xx xx xx xx xx xx xx xx xx xx xx xx 04 08 yy yy yy yy yy yy yy yy
   02 01 zz, where xx..xx is the Modifier, yy..yy is the Routing
   Prefix, and zz is the Collision Count. All the 29 octets are
   included in the input to Hash1. Only the 12 octets xx..xx are
   included in the input to Hash2.

4. CGA Generation

   The process of generating a new CGA takes three input values: a 64-
   bit Routing Prefix, the Public Key of the address owner, and the
   security parameter Sec, which is an unsigned 3-bit integer. The
   result is a new CGA and the associated self-signed certificate (as
   defined in Sections 2-3). The cost of generating a new CGA depends
   on the security parameter Sec, which gets values from 0 to 7.

   If Sec=0, a CGA can be generated from the hash input with the
   following steps:

    (1)  DER-encode the address owner's public key as an ASN.1
         structure of the type SubjectPublicKeyInfo.

    (2)  Create an ASN.1 structure of type CGAParameters. Set the
         modifier data value to 12 zero octets. Set the routingPrefix
         data value to be the Routing Prefix. Set the collisionCount
         data value to zero. DER-encode the CGAParameters data value.

    (3)  Concatenate the DER-encoded SubjectPublicKeyInfo and
         CGAParameters data values. Execute the MD5 algorithm on the
         concatenation. The result is Hash1.

    (4)  Concatenate the 64-bit Routing Prefix and the rightmost 64
         bits of Hash1 to form a 128-bit IPv6 address.

    (5)  Set the group and universal bits in the address both to 1
         and the three rightmost bits of the address all to 0.

    (6)  If an address collision is detected, increment the
         collisionCount data value in the DER-encoded CGAParameters
         data value and go back to step (3). However, after three
         collisions, stop and report the error.

    (7)  Create and sign a self-signed X.509 v3 certificate using the
         SubjectPublicKeyInfo data item created in step (1). Include
         in the certificate an extension where the extnID has the
         value cgaExtnID, critical has the value false or true, and
         the extnValue contains the encoded CGAParameters data value



Aura                  Expires August 24, 2003              [Page 6]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003

         from step (2). The certificate MAY contain other fields and
         extensions.

   If the generated CGA will be used only in protocols that that use
   the optimized parameter format, step (9) MAY be skipped.

   Nodes MAY set the security parameter Sec to zero and implement only
   the above procedure, which is deterministic and relatively fast.
   However, it is RECOMMENDED that implementations support the
   generation of addresses with higher Sec values. For any Sec value
   from 0 to 7, a CGA can be created as follows:

    (1)  DER-encode the address owner's public key as an ASN.1
         structure of the type SubjectPublicKeyInfo.

    (2)  Create an ASN.1 structure of type CGAParameters. Set the
         modifier data value to 12 random octets. Set the
         routingPrefix data value to be the Routing Prefix. Set the
         collisionCount data value to zero. DER-encode the
         CGAParameters data value.

    (3)  Concatenate the DER-encoded SubjectPublicKeyInfo and
         modifier data values. Execute the MD5 algorithm on the
         concatenation. The result is Hash2.

    (4)  Compare the 12*Sec leftmost bits of Hash2 with zero. If they
         are all zero (or if Sec=0), continue with the step (5).
         Otherwise, increment the modifier data value (as if the
         content octets of the modifier were a 96-bit integer) and go
         back to step (3).

    (5)  Concatenate the DER-encoded SubjectPublicKeyInfo and
         CGAParameters data values. Execute the MD5 algorithm on the
         concatenation. The result is Hash1.

    (6)  Concatenate the 64-bit Routing Prefix and the rightmost 64
         bits of Hash1 to form a 128-bit IPv6 address.

    (7)  Set the group and universal bits in the address both to 1
         and the three rightmost bits of the address to the value
         Sec.

    (8)  If an address collision is detected, increment the
         collisionCount data value in the encoded CGAParameters data
         value and go back to step (5). However, after three
         collisions, stop and report the error.

    (9)  Create and sign a self-signed X.509 v3 certificate using the
         SubjectPublicKeyInfo data item created in step (1). Include


Aura                  Expires August 24, 2003              [Page 7]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003

         in the certificate an extension where the extnID has the
         value cgaExtnID, critical has the value true or false, and
         the extnValue contains the encoded CGAParameters data value
         from step (2). The certificate MAY contain other fields and
         extensions.

   If the generated CGA will be used only in protocols that that use
   the optimized parameter format, step (9) MAY be skipped.

   Note 1: The initial value of Modifier in step (1) and the method of
   modifying it in step (4) MAY be chosen arbitrarily. In order to
   avoid trying the same Modifier values repeatedly, it is RECOMMENDED
   that the initial value is chosen randomly. The quality of the
   random number generator is not important as long as the same values
   are not repeated frequently. The RECOMMENDED way to modify Modifier
   is to increment the content octets of the modifier data value as if
   they were an unsigned 96-bit integer. (Octet order can be chosen
   arbitrarily and overflows can be ignored.)

   Note 2: For security parameter values greater than 0, this second
   algorithm is not guaranteed to terminate after a certain number of
   iterations. The brute-force search in steps (3)-(4) takes on the
   average approximately 2^(12*Sec) iterations to complete.

   Note 3: If the Routing Prefix of the address changes but the
   address owner's public key does not, the old value of Modifier can
   be used and it is unnecessary to repeat the brute-force search.

5. CGA Verification

   CGA verification takes two inputs: an IPv6 address and a self-
   signed X.509 v3 certificate. In protocols where saving octets is
   essential, the certificate MAY be replaced by the optimized
   parameter format (i.e. a concatenation of the DER-encoded
   SubjectPublicKeyInfo and CGAParameters data items). The
   verification either succeeds or fails. If the verification
   succeeds, the verifier knows that the certificate contains the
   public key of the address owner. The verifier can then use the
   public key to authenticate signed messages from the address owner
   or to exchange a session key with the address owner.

   The CGA is verified with the following steps:

    (1)  Compare the group and universal bits in the address to one.
         If either bit is zero, the address is a non-CGA address and
         no verification can be done.

    (2)  Read the security parameter Sec from the three rightmost
         bits of the address. (Sec is an unsigned 3-bit integer.)


Aura                  Expires August 24, 2003              [Page 8]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003


    (3)  Find the encoded subjectPublicKeyInfo data value in the
         certificate.

    (4)  Find and decode a certificate extension with extnID value
         equal to cgaExtnID. Decode the content octets of the
         corresponding extnValue data value, which have the type
         CGAParameters. Check that the collisionCount value is 0, 1
         or 2. The CGA verification fails if the extension does not
         exist, if decoding of the extension fails, or if the
         collisionCount value is out of range.

    (5)  Check that the routingPrefix data value is equal to the
         Routing Prefix (i.e. leftmost 64 bits) of the address.

    (6)  Concatenate the encoded SubjectPublicKeyInfo and
         CGAParameters data values. Execute the MD5 algorithm on the
         concatenation. The result is Hash1.

    (7)  Take the rightmost 64 bits of Hash1 output and compare them
         with the Interface Identifier (i.e. the rightmost 64 bits)
         of the address. Differences in the group and universal bits
         and in the three rightmost bits are ignored. If the 64-bit
         values differ (other than in the five ignored bits), the CGA
         verification fails.

    (8)  Concatenate the encoded SubjectPublicKeyInfo and modifier
         data values. Execute the MD5 algorithm on the concatenation.
         The result is Hash2.

    (9)  Compare the 12*Sec leftmost bits of Hash2 with zero. If any
         one of these is non-zero, CGA verification fails. If Sec=0,
         verification never fails at this step.

    (10)
          Verify the signature on the self-signed certificate. If the
         signature is invalid, the GCA verification fails. Otherwise,
         the CGA verification succeeds.

   All nodes that verify CGAs MUST be able to process all security
   parameter values Sec = 0, 1, 2, 3, 4, 5, 6, 7. The verification
   procedure is relatively fast and always requires a constant amount
   of computation.

   In protocols where the optimized parameter format is used instead
   of the certificate format, the signature verification in step (10)
   is skipped.

   Note 1: The values of Modifier and Collision Count are ignored in
   the CGA verification procedure, except for checking that Collision


Aura                  Expires August 24, 2003              [Page 9]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003

   Count is in the allowed range in step (3) and for including them
   into the appropriate hash inputs.

6. Security Considerations

   The purpose of CGA addresses is to prevent stealing and spoofing of
   IPv6 addresses. The public key of the address owner is bound
   cryptographically to the address. The address owner can use the
   corresponding private key to assert its ownership of the address
   and to sign messages sent from the address.

   It is important to understand that that attacker can create a new
   address from an arbitrary routing prefix and its own public key.
   What the attacker cannot do is to impersonate somebody else's
   address. This is because the attacker would have to find a
   collision of the cryptographic hash value Hash1. (The property of
   the hash function needed here is called second pre-image
   resistance.)

   The signature on the self-signed certificate proves that the owner
   of the public key wants to be associated with the address. The
   signature also binds other certificate fields to the address.
   Protocols that use CGAs but need to bind additional information
   (other than the public key) to the address may define new
   certificate extensions for this purpose.

   Some CGA applications may need to sign individual IPv6 packets. A
   CGA-signed packet will have the CGA address as its source address,
   and it will have to contain the associated certificate, a payload,
   and a signature. There is the problem that the packet size may
   exceed the Ethernet MTU. In that case, the optimized parameter
   format, rather than the full certificate, can be sent to the
   verifier. (In fact, the full certificate need not be created if it
   is not needed for other protocols.) Protocols that use this
   optimization obviously cannot require verification of the signature
   on the certificate. These protocols should include the source
   address of the packet in the signed message in order to prove that
   the public-key owner wants to use the address. For simplicity, the
   signature on the self-signed certificate MUST always be verified if
   a certificate is available to the verifier.

   As computers become faster, the 64 bits of the Interface Identifier
   will not be sufficient to prevent attackers from searching for hash
   collisions. It helps somewhat that we include the routing prefix of
   the address in the hash input. This prevents the attacker from
   using a single pre-computed database to attack addresses with
   different routing prefixes. The attacker needs to create a separate
   database for each routing prefix. Link-local addresses are,



Aura                  Expires August 24, 2003             [Page 10]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003

   however, left vulnerable because the same routing prefix is used by
   all IPv6 nodes.

   In the long term, some kind of hash extension technique must be
   used to counter the effect of faster computers. Otherwise, the CGA
   technology could become outdated after 5-20 years. The idea in this
   document is to increase the cost of both address generation and
   brute-force attacks by the same parameterized factor while keeping
   the cost of address use and verification constant. This provides
   protection also for link-local addresses.

   For this purpose, the input to a second hash function Hash2 is
   modified by varying the value of Modifier until the leftmost 12*Sec
   bits of Hash2 are zero. This increases the cost of address
   generation approximately by a factor of 2^(12*Sec). It also
   increases the cost of brute-force attacks by the same factor. That
   is, the cost of creating a certificate that binds the attacker's
   public key with somebody else's address is increased approximately
   by a factor of 2^(12*Sec). The address owner may choose the
   security parameter Sec depending of its own computational capacity
   and the expected lifetime of the address. Currently, Sec values
   between 0 and 2 are sufficient for most IPv6 nodes. As computers
   become faster, higher Sec values will slowly become useful.

   Theoretically, if a typical attacker is able to tap into N local
   networks at the same time, an attack against link-local addresses
   is N times as efficient as an attack against addresses of a
   specific network. This effect can be countered by using log2(N)
   bits longer hash extensions for link-local addresses than for
   global-scope addresses. (Incrementing Sec by one causes a 12-bit
   increase in the length of the hash extension.)

   In order to make it possible for mobile nodes whose routing prefix
   changes frequently to use Sec values greater than 0, we have
   decided not to include the routing prefix in the input of Hash2.
   The result is weaker than if the routing prefix were included in
   the input of both hashes. On the other hand, our scheme is at least
   as strong as using the hash extension technique without including
   the routing prefix in either hash. It is also at least as strong as
   not using the hash extension but including the routing prefix. This
   trade-off was made because mobile nodes frequently move to insecure
   networks where they are at the risk of denial-of-service attacks,
   for example, during the duplicate address detection procedure.

   In most applications of CGA, the goal is prevent denial-of-service
   attacks. Therefore, it is usually sensible to start by using a low
   Sec value and to replace addresses with stronger ones only when
   denial-of-service attacks based on brute-force search become a
   significant problem. On the other hand, if CGA is used as a part of


Aura                  Expires August 24, 2003             [Page 11]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003

   a strong authentication or secrecy mechanisms (e.g. CGA
   authentication plus Secure DNS), then it may be necessary to start
   with higher Sec values. (Fortunately, link-local addresses are not
   used in the latter kind of applications.)

   Collision Count is used to modify the input to Hash1 if there is an
   address collision. It is important not to allow Collision Count
   values higher than 2. First, it is extremely unlikely that three
   collisions would occur and the reason is certain to be either a
   configuration or implementation error or a denial-of-service
   attack. (These DoS attacks can be prevented if the IPv6 neighbor
   discovery messages are authenticated with CGA addresses.) Second,
   an attacker who is doing a brute-force search to match a given CGA
   address can try all different values of Collision Count without
   repeating the brute-force search for Modifier. Thus, the more
   different values are allowed for Collision Count, the less
   effective the hash-extension technique is in preventing brute-force
   attacks.

   It is important to understand that when a CGA address is used to
   authenticate messages from an IPv6 node, the receiver of the
   message must know the exact IPv6 address. In network layer
   signaling, such as duplicate address detection and Mobile IPv6
   binding updates, the IPv6 address is the natural identifier for a
   network node. In other applications, such as opportunistic IPSec,
   it is possible to get around the protection by tricking the
   receiver into accept the wrong IPv6 address, e.g. by DNS spoofing,
   unless the address resolution is protected by at least equally
   strong mechanisms.

   Finally, CGA-based authentication has some implications on privacy.
   The CGA addresses can be randomized by choosing a random initial
   value for Modifier and by generating a new address at desired
   intervals. If the node reveals the associated certificate or public
   key to its correspondents, it should also replace the public key at
   the same time as the address. This gives the same level of
   protection as the IPv6 address privacy extensions [ND01]. However,
   the cost of public-key and address generation may imply less
   frequent address changes.

Acknowledgments

   Many of the ideas in this draft were influenced by Michael Roe,
   Christian Huitema and Pekka Nikander.

Intellectual Property Statement

   The author believes that there are several patents or patent
   applications that cover parts of this specification.


Aura                  Expires August 24, 2003             [Page 12]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003


References

   [AAK+02] Jari Arkko, Tuomas Aura, James Kempf, Vesa-Matti
   M„ntyl„, Pekka Nikander, and Michael Roe. Securing IPv6 neighbor
   discovery and router discovery. In Proc. 2002 ACM Workshop on
   Wireless Security (WiSe), pages 77-86, Atlanta, GA USA, September
   2002. ACM Press.

   [Eas99] Donald Eastlake. Domain name system security extensions. RFC
   2535, IETF Network Working Group, March 1999.

   [HD98] Robert M. Hinden and Stephen E. Deering. IP version 6
   addressing architecture. RFC 2373, IETF Network Working Group, July
   1998.

   [HFPS02] Russell Housley, Warwick Ford, Tim Polk, and David
   Solo. Internet X.509 public key infrastructure certificate and
   certificate revocation list (CRL) profile. RFC 3280, IETF Network
   Working Group, April 2002.

   [ITU97] International Telecommunication Union. ITU-T recommendation
   X.509 (1997 E): Information technology - open systems
   interconnection - the directory: Authentication framework, June
   1997.

   [ITU02] International Telecommunication Union. ITU-T recommendation
   X.690, information technology -- ASN.1 encoding rules:
   Specification of basic encoding rules (BER), canonical encoding
   rules (CER) and distinguished encoding rules (DER), July 2002. Also
   appeared as ISO/IEC International Standard 8825-1.

   [JB99] Stephen Kent and Randall Atkinson. Security architecture for
   the Internet Protocol. RFC 2401, IETF Network Working Group,
   November 1998.

   [MC02] Gabriel Montenegro and Claude Castelluccia. Statistically
   unique and cryptographically verifiable identifiers and addresses.
   In Proc. ISOC Symposium on Network and Distributed System Security
   (NDSS 2002), San Diego, February 2003.

   [Mos01] Robert Moskowitz. Host identity payload and protocol.
   Internet-Draft draft-ietf-moskowitz-hip-05.txt, October 2001. Work
   in progress.

   [ND01] Thomas Narten and Richard Draves. Privacy extensions for
   stateless address autoconfiguration in IPv6. RFC 3041, IETF Network
   Working Group, January 2001.



Aura                  Expires August 24, 2003             [Page 13]


INTERNET-DRAFT      MIPv6 BU Attacks and Defenses       February 2003

   [NN98] Thomas Narten, Erik Nordmark, and William Allen Simpson.
   Neighbor discovery for IP version 6 (IPv6). RFC 2461, IETF Network
   Working Group, December 1998.

   [Nik01] Pekka Nikander. A scaleable architecture for IPv6 address
   ownership. Internet-draft, March 2001. Work in Progress.

   [OR01] Greg O'Shea and Michael Roe. Child-proof authentication for
   MIPv6 (CAM). ACM Computer Communications Review, 31(2), April 2001.

   [TN98] Susan Thomson and Thomas Narten. IPv6 stateless address
   autoconfiguration. RFC 2462, IETF Network Working Group, December
   1998.

Authors' Addresses

   Tuomas Aura
   Microsoft Research
   7 J J Thomson Avenue
   Cambridge, CB3 0FB
   United Kingdom

   Phone: +44 1223 479708
   Email: tuomaura@microsoft.com




























Aura                  Expires August 24, 2003             [Page 14]