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

Versions: 00 01 02

Network Working Group                                     Sheng Jiang
Internet Draft                                        Sam(Zhongqi) Xia
Expires: January 2009                     Huawei Technologies Co., Ltd
                                               Alberto Garcia-Martinez
                                                                 UC3M
                                                       July 11th, 2008


Requirements for configuring Cryptographically Generated Addresses (CGA)
             and overview on RA and DHCPv6-based approaches
                draft-jiang-sendcgaext-cga-config-02.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   This document may only be posted in an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html

   This Internet-Draft will expire on January 10, 2009.



Abstract

   This document analyzes the requirements for the configuration
   Cryptographically Generated Addresses and Multi-key CGAs. The
   applicability of Router Advertisement and DHCPv6 for this
   configuration is also discussed.






Jiang, et al.          Expires January 10, 2009                [Page 1]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


Table of Contents


   1. Introduction................................................2
   2. Terminology.................................................3
   3. Requirements................................................3
      3.1. Configuration of the parameters required for the generation
      of CGA......................................................3
         3.1.1. Offloading the large computational burden...........4
         3.1.2. Certificate information dissemination..............5
      3.2. CGA granting and registration...........................5
      3.3. Configuration the parameters in order to enable the CGA proxy
       ............................................................5
   4. Approaches overview.........................................6
      4.1. Node requests CGA-related configuration parameters to the
      DHCPv6 server...............................................7
      4.2. Node requests to the DHCPv6 server the computation of the
      Modifier....................................................7
      4.3. Node requests DHCPv6 server to grant the CGA............8
      4.4. Node sends MCGA-specific information to the DHCPv6 server8
   5. Security Considerations......................................8
      5.1. Threat Analysis of the Configuration Requirements........8
         5.1.1. Threats faced by the end hosts.....................8
         5.1.2. Threats faced by the configuration servers and proxies10
      5.2. Threat Analysis of the Approaches Proposed.............10
         5.2.1. Router Advertisement with SEND support............11
         5.2.2. Router Advertisement without SEND support..........11
         5.2.3. DHCPv6...........................................11
   6. IANA Considerations........................................12
   7. Conclusions................................................12
   8. Acknowledgments............................................12
   9. References.................................................12
      9.1. Normative References...................................12
      9.2. Informative References.................................13
   Author's Addresses............................................14
   Intellectual Property Statement................................14
   Disclaimer of Validity........................................15
   Copyright Statement...........................................15



1. Introduction

   Cryptographically Generated Addresses (CGA, [RFC3972]) provide means
   to verify the ownership of IPv6 addresses without requiring any
   security infrastructure such as a certification authority. As an
   extension to enable SEure Neighbor Discovery (SEND, [RFC3971]) proxy


Jiang, et al.         Expires January 10, 2009                [Page 2]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


   support, multi-key CGAs [MCGA] have been introduced. The use of both
   types of addresses has been proposed for allowing identity
   verification in different protocols, such as SEND, Enhanced Route
   Optimization for MIPv6 [RFC4866] or SHIM6 [SHIM6-proto].

   In the current specifications, there is a lack of procedures to
   enable proper management of CGA generation, in particular, in the
   configuration of the parameters that define the security properties
   of the addresses. Additionally, there is a lack of tools for
   informing the hosts about the availability of SEND proxies, and
   exchanging the required information with the proxies. Finally, there
   are no means to delegate the computation of the Modifier, a CPU
   intensive operation, to faster or non battery-dependant resources.

   This draft analyses the configuration requirements raised by CGA and
   MCGA generation. Additionally, the applicability of Router
   Advertisement and Dynamic Host Configuration Protocol for IPv6
   (DHCPv6 [RFC3315]) for performing this configuration is discussed.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

3. Requirements

   The CGA specifications [RFC3972, MCGA] define the procedure to
   generate a CGA. However, these procedures do not allow the
   enforcement of a given configuration to a group of hosts, nor address
   the interactions between end hosts and proxies required for proxy
   configuration. It does also not consider the delegation of CPU-
   intensive operations to other nodes. In this section, we analyze the
   scenarios in which these operations are required.

3.1. Configuration of the parameters required for the generation of CGA

   The CGA associated Parameters used to generate a CGA includes several
   parameters [RFC 3972]:

     - a Public Key,

     - a Subnet Prefix,

     - a 3-bit security parameter Sec,




Jiang, et al.         Expires January 10, 2009                [Page 3]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


     - a Modifier that is selected so that the result of a hash to
     comply with the requirements introduced by the value of a security
     parameter Sec in order to provide protection against brute-force
     attacks,

     - a Collision Count value, increased each time the address
     generated results in a collision in the subnet considered,

     - any Extension Fields that could be used.

   Additionally, it should be noted that the hash algorithm to be used
   in the generation of the CGA is also defined by the Sec value
   [RFC4982].

   Currently, there are convenient mechanisms for allowing an
   administrator to configure the subnet prefix for a host. Other
   parameters used for generating the CGA could also benefit from the
   possibility of being configured by the administrator. For instance,
   the administrator can determine, according to the type of
   infrastructure and the security needs, the Sec value that should be
   used by the hosts to generate the CGA.

   When appropriate, the Extension Fields could also be mandated by the
   administrator.

   Upon reception of this information, the end hosts SHOULD generate
   addresses compliant with the received parameters. If the parameters
   change, the end hosts SHOULD generate new addresses compliant with
   the parameters propagated.

3.1.1. Offloading the large computational burden

   An important case to consider is the large computational consumption
   of the generation of the Modifier field. The Modifier is a 128
   unsigned integer that is selected so that the Hash2 operation defined
   in RFC 3972 results in the required number of leftmost 0 bits. The
   higher the number of bits required being 0, the more secure a CGA is
   against brute-force attacks. However, high number of bits also
   results in additional computational cost for the generation process,
   cost that could be deemed excessive in certain environments, such as
   mobile terminals with low computing power. As an example, consider a
   Sec value equals 2, requesting the leftmost 32 bits of a SHA-1 Hash2
   to be zero. For assuring this, a system has to generate in mean 2^32
   different modifiers, and perform the Hash2 operation to check the
   bits required to be 0. An estimation of the CPU power required to do
   this can be obtained as following: openSSL can perform in an Intel
   Core2-6300 on an Asus p5b-w motherboard close to 0.87 million of SHA-


Jiang, et al.         Expires January 10, 2009                [Page 4]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


   1 operations on 16 byte blocks per second. Since the input data of
   Hash2 operation is larger than 16 bytes, this value is an upper bound
   for the number of hash operations that can be performed for
   generating the modifier. Checking 2^32 different modifiers requires
   around 5000 seconds. The high number of required operations can
   represent a problem for end hosts (i.e. mobile devices) with much
   lower computing power than considered in the example, and/or with
   restrictions in battery resources. For these cases, a mechanism for
   delegating the computation of the modifier should be provided.

3.1.2. Certificate information dissemination

   CGAs enable the verification of the relationship between a
   public/private key pair (certificate) and an address. However, it
   does not verify the identity of a sender. In most of scenarios, it is
   necessary to know which certificates or certificate chains are
   trustworthy. Mechanisms are required to disseminate such information
   to CGA receivers.

3.2. CGA granting and registration

   The usage of self-generated CGAs may need to be granted by the
   networking management plate. Only granted CGAs are allowed to be used
   to access the network. It is also validated whether the CGAs do not
   use the reserved range of interface identifier [RIID].

   As described in RFC 3972, the modifier can be reused when the prefix
   of the CGA changes and this is the only change. However, when a
   mobile node moves from a network to another, not only the prefix
   changes, but also other CGA relevant parameters may change. Therefore,
   any CGAs generated by the node itself should also be granted by the
   networking management plate.

   A node that has generated a CGA could register the resulting address
   so that a central administration could manage this information. The
   node could be requested to perform this registration.

3.3. Configuration the parameters in order to enable the CGA proxy

   In order to preserve location privacy of CGAs, the CGA proxy
   solutions, such as Multi-Key Cryptographically Generated Addresses
   (MCGAs), are introduced. These CGA proxy solutions require that
   certain information/parameters of proxy are configured.

   First of all, end hosts should be notified that their SEND validation
   could be proxied, and therefore that they should generate MCGA
   addresses. In order to generate the MCGA, and in addition to the Sec


Jiang, et al.         Expires January 10, 2009                [Page 5]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


   parameter and Extension Fields required for CGA bootstrapping, the
   node must know the node's own public key and the public key(s) from
   its proxy(s), which are certified router public keys. RFC 3971
   describe a mechanism that allows the node to obtain the public keys
   of the router(s), although other protocols could be used for this
   purpose.

   Upon reception of this information, the end hosts SHOULD generate
   MCGAs compliant with the received parameters. If the parameters
   change, the end hosts SHOULD generate new MCGAs compliant with the
   parameters propagated.

   Additionally, the proxy(s) should be notified the new MCGA and its
   associated CGA Parameters Data Structure, so that the proxy could
   securely proxy the MCGA by signing the message with its own private
   key. Consequently, a mechanism for making proxy(s) aware of the keys
   used by each end host should be provided.

4. Approaches overview

   Among the mechanisms in which configuration parameters could be
   pushed to the end hosts and/or CGA related information sent back to a
   central administration, we discuss two mechanisms: the stateless
   address configuration mechanism based in Router Advertisement, and
   the stateful configuration mechanism based in DCHPv6.

   On one hand, Router Advertisement could be extended with an option
   that could convey parameters related with CGA configuration, such as
   the value of the Sec or the values of future Extension Fields, etc.
   In this way, a router could distribute these parameters to all the
   hosts of the subnet through Router Advertisement, in the same message
   in which prefix information is conveyed.

   On the other hand, DHCPv6 can be extended to:

     - propagate to the end hosts the values of the basic parameters
     required to configure CGAs,

     - request the node to propagate to the server the resulting CGA
     address,

     - grant the node to use its self-generated CGA address,

     - obtain from the end host CGA information to update any database
     with the addresses being used,

     - inform the end hosts about the convenience for generating MCGA,


Jiang, et al.         Expires January 10, 2009                [Page 6]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


     - obtain from the end hosts the MCGA information required to
     configure the proxy(s),

     - receive requests for generating a Modifier according to a given
     security configuration, and returning the result to the end host.

   Finally, both Router Advertisement and DCHPv6 could be combined in
   the following cases:

     - when the node is requested by Router Advertisement to register
     the resulting CGA, DHCPv6 could be used to inform the DHCPv6 server
     about the resulting address,

     - when MCGA address are generated, Router Advertisement could be
     used to propagate the basic CGA parameters, and a notification that
     the end host should generate MCGA, and use DHCPv6 to inform the
     DHCPv6 server about the public key material used for MCGA
     generation,

     - when the node solicits the computation of the Modifier, after
     receiving a Router Advertisement with the Sec parameters and
     Extension Fields, it can issue the request through a DHCPv6
     exchange.

   We next describe in more detail the interactions foresee for DHCPv6.

4.1. Node requests CGA-related configuration parameters to the DHCPv6
   server

   A node may initiate a request for the relevant CGA configuration
   information needed to the DHCPv6 server. The server responds with the
   configuration information for the node. The server also sends its
   known certification information for the node. If registration of the
   resulting address is required, the server can include such
   requirement in the message sent. If SEND proxies are available, the
   server informs the node that an MCGA should be generated. The public
   keys for the routers, along with their certificates, could be
   included in the response.

   After receiving the configuration information, the node generates a
   CGA (or a MCGA) based on its public key and the configuration
   information.

4.2. Node requests to the DHCPv6 server the computation of the Modifier

   A node may initiate a request for the computation of the Modifier for
   a certain security configuration to the DHCPv6 server. The node


Jiang, et al.         Expires January 10, 2009                [Page 7]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


   includes the values selected for the CGA associated parameters, such
   as its public key, the value of the Sec parameter, etc. The server
   either computes the Modifier value, or redirects the computation to
   other node using a mechanism that is out of the scope of this draft.
   Once the server obtains the modifier, it computes the CGA or MCGA
   according to the process described in RFC 3972, and it responds to
   the node with the resulting address and the CGA Parameters Data
   Structure.

4.3. Node requests DHCPv6 server to grant the CGA

   A node requests DHCPv6 server to grant a CGA generated by the node
   itself, listing the CGA addresses in IA options [RFC3315]. According
   to whether the CGA matches the CGA-related configuration parameters
   of the network, the DHCPv6 server sends an acknowledgement to the
   node, grant the usage of the CGA or indicate the node that it must
   generate a new CGA with the CGA-related configuration parameters of
   the network. In the meantime, the DHCPv6 server has had the
   opportunity to log the address/host combination.

4.4. Node sends MCGA-specific information to the DHCPv6 server

   A node that has generated its MCGA informs the DHCPv6 server about
   the MCGA and its associated CGA Parameters Data Structure. The DHCPv6
   server sends an acknowledgement to the node. The server or the node
   also needs to notify this information to the routers acting as SEND
   proxies, in a way that is out of the scope of this document.

5. Security Considerations

5.1. Threat Analysis of the Configuration Requirements

5.1.1. Threats faced by the end hosts

   We first discuss the threats that the clients may face as a result of
   the operations described in this document.

   Regarding to the configuration of the Sec parameter, one risk is that
   a malicious node could propagate a Sec value providing less
   protection than intended by the network administrator, facilitating a
   brute force attack against the hash, or the selection of the weakest
   hash algorithm available for CGA definition. Even in the worst case,
   if the hash algorithm cannot be inverted, the expected number of
   iterations required for a brute force attack is O(2^59) in order to
   find a CGA Parameters Data Structure that matches with a given node.




Jiang, et al.         Expires January 10, 2009                [Page 8]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


   Another risk is the use of a Sec, higher than intended by the
   administrator, which would require a large number of resources of the
   client to compute the modifier, requiring a long time until the
   device can communicate. This can be considered a kind of DOS attack.
   A variation of this attack is the propagation of different Sec values
   could force the nodes to generate different addresses, requiring the
   generation of a new modifier, etc. The end host SHOULD store the
   addresses that were generated in the past according to different Sec
   values.

   The disclosure of the Sec value to any party does not represent any
   threat.

   The analysis of the threats for the configuration of CGA Extension
   Fields should be performed in a case-by-case basis.

   Regarding to the propagation of MCGA-related information, an attacker
   could generate a key pair, and propagate the public key to the end
   host, so the MCGA generated were associated with the public key of
   the attacker, In this way, the attacker would be able to impersonate
   the end host for all the protocols for which MCGA were used, such as
   SEND. Note that the privacy features included in the MCGA design
   prevents correspondent nodes from realizing that the end host
   identity has been stolen.

   In addition, an attacker could propagate different public keys at a
   high frequency, forcing the end host to generate new MCGAs, resulting
   if repeated in a DOS attack.

   The disclosure of the public keys of the proxy(s) or end host(s) used
   to build the MCGA does not represent any threat.

   Finally, we consider the delegation of the Modifier computation. The
   configuration at a given end host of a Modifier not compliant with
   the Sec requirement could break any identity validation performed at
   other hosts, and consequently, could prevent any communication.
   However, this event can be easily detected at the end host by a
   performing the Hash2 computation and certifying that results in the
   required number of 0 bits. If it were impossible to obtain a valid
   Modifier, the end host would be forced to compute by itself the
   modifier, falling back to the current standard procedure.

   It is worth to note that the proposed operations do not exchange
   private keys. An operation requiring such exchange would be the
   generation of a CGA/MCGA in a different location than the final end
   host to which it is assigned. The benefits do not outweigh the risks.
   On one hand, the gain would be small, since a CGA-enabled host is


Jiang, et al.         Expires January 10, 2009                [Page 9]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


   expected to dynamically sign and validate signatures, and the cost of
   generating a key pair is not much higher. On the other hand, there
   are significant risks, associated to the fact that the compromise of
   the node generating the keys results in the compromise of the
   identities of many other systems, and the need for assuring private
   communications among the parties involved (possibly requiring
   cryptographic tools, key distribution, etc.)

5.1.2. Threats faced by the configuration servers and proxies

   In general, the threats that the configuration servers may face are
   related with DOS.

   An attacker could generate CGA registration requests in order to
   exhaust the server resources (or to impact on any other operation
   that depend on the registration of the CGAs). The considerations for
   MCGAs are similar, although in this case the impact is extended to
   proxies.

   However, the most dangerous attack is bound to malicious requests to
   compute the Modifier, since the CPU cost for the server can be high,
   especially considering that the attacker could select a Sec value
   requiring the highest number of computations for the server.

   We also consider the threats involved in the delivery of the
   information used to build a MCGA to a SEND proxy. In this case, an
   attacker could generate fake information in order to exhaust the
   resources at the proxy. While computing resources are not compromised,
   since the only check required at the proxy is that its own certified
   key is included, the state associated to the proxy operation could be
   exhausted, or proxy operation slowed down.

5.2. Threat Analysis of the Approaches Proposed

   Now we discuss the security implications of the use of Router
   Advertisement and DHCPv6 for performing the proposed operations. To
   analyze the different scenarios regarding to security in which they
   can be applied, it is worth to note that the use of CGAs and MCGAs is
   not bound to SEND enabled networks, since they could be used for
   identity protection in other protocols such as MIPv6 or SHIM6.
   Therefore, we can consider different scenarios regarding to security:
   Router Advertisement with SEND support, Router Advertisement without
   SEND support, and DHCPv6. For Router Advertisement approaches, only
   parameter propagation and SEND proxy public key distribution are to
   be considered.




Jiang, et al.         Expires January 10, 2009               [Page 10]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


5.2.1. Router Advertisement with SEND support

   Since the integrity of the RA messages and the identity of their
   sender are protected by the SEND protocol, protection against
   malicious nodes generating inappropriate values for the Sec parameter
   or the Extension Fields is provided. The same protection is provided
   for the distribution of the public keys of the proxies required for
   MCGA generation. In this case, a trust anchor must have been
   configured in the client previously to the reception of the RA
   messages.

5.2.2. Router Advertisement without SEND support

   In this case there is no protection against the generation of
   different Sec values, so an attacker could force the generation of
   CGA with the lowest protection allowed by the standard. It could also
   force the generation of up to 8 CGA addresses in the end host,
   wasting resources from the end host. Another attack is related with
   the association of the public key of an attacker to the MCGA of the
   end host. DOS attacks based on the request of multiple MCGAs could be
   issued, although in this case a rate limit set in the client could
   mitigate the impact.

   However, it should be noted that an attacker being able to generate
   Router Advertisements could also perform Man-In-The-Middle or DOS
   attacks, by registering itself as a default router for the subnet.

5.2.3. DHCPv6

   All the configuration operations proposed in this document are
   initiated by the end host. From the point of view of the end host,
   the difficulty of generating fake responses that were accepted by the
   end host with the same transaction-id at the precise time is
   outstanding. However, attacks can be generated by nodes placed in
   path between the requesting end host and the DHCPv6 server. In
   particular, non-SEND enabled subnets are more prone to this type of
   attacks, although SEND does not provide full protection against MITM
   attacks. In this case, the Sec parameter could be forced to be the
   lowest, the node could be forced to compute up to 8 CGA addresses, or
   to compute MCGAs associated with the attacker.

   The mechanism based on DHCPv6 is also vulnerable to DOS attacks to
   the server, such as registration of large number of CGA, or request
   for Modifier computation.





Jiang, et al.         Expires January 10, 2009               [Page 11]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


   Proper use of DHCPv6 autoconfiguration facilities [RFC3315], such as
   AUTH option, can prevent these threats, provided that a configuration
   token is known to both the client and the server.

   Note that, as expected, it is not possible to provide secure
   configuration of CGA or MCGA without a previous configuration of
   security information at the client (either a trust anchor, a DHCPv6
   configuration token...). However, considering that the values of
   these elements could be shared by the nodes in the network segment,
   these security elements can be configured more easily in the end
   nodes than its addresses.

6. IANA Considerations

   This document defines only the interaction models that involve the
   Router Advertisement and the DHCPv6 protocol in the CGA generation
   procedure. The actual DHCPv6 and Router Advertisement extensions are
   defined in other documents.

7. Conclusions

   This document analyses the requirements for the configuration
   Cryptographically Generated Addresses (CGA) and Multi-key CGAs. A
   central administration could configure some parameters such as Sec or
   Extension Fields to be used by the end hosts in CGA generation. The
   central administration could notify the availability of CGA proxies,
   requesting the generation of MCGAs, and propagating the keying
   material required for MCGAs, and obtaining the end host specific
   material resulting from this address generation. The computation of
   the Modifier could also be delegated by an end host to a more
   appropriate system.

   The tools discussed for this performing these interactions are Router
   Advertisement and the DHCPv6 protocol.

8. Acknowledgments

   The authors would like to thank Marcelo Bagnulo Braun for been
   involved in the early requirement identification.

9. References

9.1. Normative References

   [RFC3315] R. Droms, Ed., "Dynamic Host Configure Protocol for IPv6",
             RFC3315, July 2003.



Jiang, et al.         Expires January 10, 2009               [Page 12]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


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

   [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972,
             March 2005.

   [RFC4982] M. Bagnulo, "Support for Multiple Hash Algorithms in
             Cryptographically Generated Addresses (CGAs) ", RFC4982,
             July 2007.

   [MCGA]  J. Kempf, "Secure IPv6 Address Proxying using Multi-Key
             Cryptographically Generated Address", draft-kempf-cgaext-
             ringsig-ndproxy-02 (work in progress), August 2007.

   [RIID]  S. Krishnan, "Reserved IPv6 Interface Identifiers", draft-
             ietf-6man-reserved-iids-00.txt (work in progress), February
             2008.

9.2. Informative References

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

   [RFC4866] J. Arkko, C. Vogt, W. Haddad, "Enhanced Route Optimization
             for Mobile IPv6", RFC4866, May 2007.

   [SHIM6-proto] E. Nordmark, M. Bagnulo, "Shim6: Level 3 Multihoming
             Shim Protocol for IPv6", draft-ietf-shim6-proto-10.txt
             (work in progress), February 2008.



















Jiang, et al.         Expires January 10, 2009               [Page 13]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


Author's Addresses

   Sheng Jiang
   Huawei Technologies Co., Ltd
   QuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base,
   Hai-Dian District, Beijing, P.R. China
   100085
   Phone: 86-10-82836774
   Email: shengjiang@huawei.com

   Sam (Zhongqi) Xia
   Huawei Technologies Co., Ltd
   QuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base,
   Hai-Dian District, Beijing, P.R. China
   100085
   Phone: 86-10-82836864
   Email: xiazhongqi@huawei.com

   Alberto Garcia-Martinez
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid  28911
   SPAIN
   Phone: 34-91-6249500
   Email: alberto@it.uc3m.es

Intellectual Property Statement

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

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




Jiang, et al.         Expires January 10, 2009               [Page 14]


Internet-Draft draft-jiang-sendcgaext-cga-config-02.txt       July 2008


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

Disclaimer of Validity

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

Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

























Jiang, et al.         Expires January 10, 2009               [Page 15]


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