Cryptographically Generated Address (CGA) Extension Header for Internet Protocol version 6 (IPv6)
draft-dong-savi-cga-header-03.txt

Abstract

This document specifies an IPv6 extension header called the Cryptographically Generated Address (CGA) Extension Header. The CGA Extension Header holds the CGA parameters associated with the source CGA of an IPv6 packet. This information can be used to validate that a particular packet was sent by the node associated with a specific CGA, enabling secure IPv6 address-based access control mechanisms.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on January 13, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

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

Table of Contents

1.  Introduction
2.  Requirements Terminology
3.  Secure Node-Based Access Control
    3.1.  Use Cases
4.  Issues with the CGA Extension Header
5.  CGA Extension Header Definition
6.  CGA Options
    6.1.  CGA Request
    6.2.  CGA Params
    6.3.  CGA Signature
7.  Packet Processing
    7.1.  Sending a CGA Request
    7.2.  Receiving a CGA Request
    7.3.  Sending CGA Params
    7.4.  Sending a CGA Signature
    7.5.  Receiving CGA Params and CGA Signature
8.  ICMP Messages
    8.1.  Verification Failure
    8.2.  Option Errors
9.  Source Address Verification
    9.1.  Initiator Verifying Responder’s Address
    9.2.  Responder Verifying Initiator’s Address
    9.3.  Bidirectional Verification
10.  Discussion
    10.1.  MTU and Fragmentation Issues
    10.2.  Strength of Security
    10.3.  Costs of Verification
11.  Security Considerations
12.  IANA Considerations
13.  Acknowledgements
14.  References
    14.1.  Normative References
    14.2.  Informative References

1.  Introduction

A Cryptographically Generated Address (CGA) is an IPv6 address that has been generated using a cryptographic key [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.). CGAs were originally designed for use in the SEcure Neighbor Discovery (SEND) protocol [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.), where they are used to verify that SEND messages have been signed by their source CGA owners without the need for any additional security infrastructure. The SEND verification mechanism depends on a set of CGA parameters that are associated with each CGA and included in every SEND packet.

This document specifies a method to carry CGA parameters in an IPv6 extension header to allow similar verification of IPv6 source CGAs across the Internet. This document specifies the details of an IPv6 CGA Extension Header containing the CGA parameters and ICMP message to report related errors. The CGA parameters can be used by any host along the path to verify that an IPv6 packet was sent by the owner of the source CGA.

2.  Requirements 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Secure Node-Based Access Control

A node-based (or IP address-based) access control list (ACL) conceptually consists of a list of nodes, specified by IP addresses or fully-qualified domain names (FQDNs). The ACL indicates which nodes are authorized to access a resource or perform a task. The IETF discourages the use of node-based ACLs, because they are inherently insecure -- it is trivial, in many cases, to send a packet from one node that uses the IP source address of another node. However, ACLs are still widely used in networks today, because of their conceptual simplicity and their ease of configuration.

By using the IPv6 CGA Extension header to verify that an IPv6 packet was sent by the node that owns the source IP address in use, it is possible to greatly improve the security of a traditional ACL. Without any additional security infrastructure or configuration, it is possible to securely verify that a packet was sent by the node that owns the authorized IPv6 source address.

Given the ability to verify that a particular packet was sent by the owner of its source CGA, it may also be possible to simplify or improve other types of access control mechanisms.

3.1.  Use Cases

Some example use cases for the CGA Extension Header include:

• Printer access control lists (ACLs), or similar ACLs, could be configured with a list of IP addresses. Access from a specific node would be authorized by placing a CGA owned by that node into the ACL. Nodes that wish to gain access would use their authorized CGA as the source address of a packet containing the CGA Extension Header, and the mechanism described in this document would be used to verify that each access attempt originated with the owner of the source CGA, before that CGA is checked against the ACL, and appropriate access is granted. This would substantially improve the security of simple ACLs, without requiring additional configuration, and without requiring any additional security infrastructure.
• Multicast replicators could be configured with a set of authorized CGA addresses. Packets would not be replicated unless the source address was verified, thus preventing the flooding of unauthorized flows.
• In cellular or wireless networks with limited radio bandwidth, the edge node that interfaces between the radio network and the wireline network could verify the signature in each packet. Unverified packets could be dropped, conserving valuable bandwidth.
• This mechanism could be used to validate that syslog messages or SNMP traps have been received from an authorized sender before logging them to disk or taking any corresponding action.
• RADIUS configuration for infrastructure nodes (routers, switches, etc.) could be substantially simplified. There are no individual users on most of these devices, and today many RADIUS servers are configured to share a password between a set of devices, thus compromising security. Instead, configuration could be reduced to configuring a list of CGA addresses for which access should be allowed.
• Dynamic DNS updates could be substantially simplified for CGA addresses, as it should be possible to allow the verified owner of a CGA to update the corresponding entry directly.

All of the examples above would require implementation changes in order to take effect. In some cases, such as the RADIUS and DDNS cases, protocol changes would also be required.

4.  Issues with the CGA Extension Header

The CGA Extension Header mechanism does have a few limitations that affect its applicability in some cases. Specifically:

• CGA addresses only offer limited security. The cryptographic strength of CGA addresses makes it 2**59 times harder to forge an address than to generate a new address. This mechanism should only be used in cases where that level of security is acceptable and/or represents a considerable improvement over current practice.
• Using CGAs, it is necessary to specify each CGA separately in an access control list, as opposed to assigning address ranges. It doesn't work to assign address ranges because the prefix portion of a CGA is not cryptographically generated, and CGA IIDs are randomly distributed across the IID space.
• CGA verification is a costly process. There is a substantial cost on the sender side to generate the per-packet signature, and a similar cost on the receiving side to perform the verification. The utility of this mechanism is limited to cases where those costs are justified and/or acceptable.

Some ideas about how to address the above issues are discussed in the "Discussion" section below.

5.  CGA Extension Header Definition

The base IPv6 specification [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) defines several extension headers and makes recommendations about how future extension headers should be defined. It also makes recommendations about the order in which extension headers should appear in IPv6 packets.

An IPv6 node that implements the CGA Extension Header defined in this document would be expected to implement, at minimum, the following IPv6 Extension Headers:

Hop-by-Hop Options Header

Destination Options Header

Routing Header

Fragment Header

CGA Extension Header

Authentication Header

Encapsulating Security Payload Header

Destination Options Header

Upper-Layer Header

When more than one extension header appears in an IPv6 packet, it is recommended that they appear in the order indicated above. Note that the CGA Extension header is currently defined to appear inside the Fragment Header. This has the implication that intermediate nodes cannot count on receiving a full CGA Extension Header in an IPv6 fragment. The trade-offs related to this choice are discussed in the "Discussion" section below.

The CGA Extension Header MUST NOT be displayed in the extension header of a packet more than once.

The CGA Extension Header is comprised of the following fields:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Next Header  |  Hdr Ext Len  |            Reserved           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  .                                                               .
  .                            Options                            .
  .                                                               .
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Next Header     8-bit selector. Identifies the type of the header
                  immediately following the CGA Extension Header.
  Hdr Ext Len     8-bit unsigned integer. Length of the header
                  in 8-octet units, excluding the first 8 octets.
                  When the value of Hdr Ext Len is zero, it means
                  that this information is for CGA initialization.
  Reserved        A 16-bit field reserved for future use. The value
                  MUST be initialized to zero by the sender and MUST
                  be ignored by the receiver.
  Options         Variable-length field.  The length of this field,
                  in octets, is determined by multiplying the value
                  of the "Hdr Ext Len" field by 8 and adding 4.
                  Contains one or more TLV-encoded options, as described
                  in section 4.2 of [RFC2460].

The Options field contains three types of options: a CGA Request, CGA Params and/or a CGA Signature. A CGA Request is used to ask the counterpart for CGA Params; the CGA Params option carries a CGA parameters data structure; and a CGA Signature contains the signature produced by the host using its private key. CGA Params MUST be accompanied with a CGA Signature, otherwise the receiver SHOULD respond with an ICMP error message. A packet MAY include CGA Signature only when CGA Params is sent. How the node handles the CGA Params in the packet before receiving CGA Request depends on the host's policy.

6.  CGA Options

6.1.  CGA Request

Any node can ask its peer for CGA Params by sending a CGA Request in the packet. The node that receives a packet containing a CGA Request, MAY respond with its own CGA Params and CGA Signature. A CGA Request has the following format:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |    Length     |            Reserved           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Sequence Number                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Type            8-bit unsigned integer. Type code for CGA Request.
                  The value is TBD2.
  Length          The length of the option (including the Type,
                  Length, Reserved and Sequence Number) in units of
                  byte.
  Reserved        An 24-bit field reserved for future use. The value
                  MUST be initialized to zero when sending, and
                  SHOULD be ignored on receipt.
  Sequence Number 32-bit unsigned integer containing a counter value
                  that is initialized to a random number and increases
                  by one for each packet sent. It may enable an
                  anti-replay service.

6.2.  CGA Params

The CGA Params option carries CGA parameters that the receiver can use to validate the source CGA. The format of the CGA Params is described in the following diagram:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |    Length     |   Pad Length  |    Reserved   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Sequence Number                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  .                                                               .
  .                         CGA Parameters                        .
  .                                                               .
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  .                             Padding                           .
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Type            8-bit unsigned integer. Type code for CGA Params.
                  The value is TBD3.
  Length          8-bit unsigned integer. The length of the option
                  (including the Type, Length, Pad Length, Reserved,
                  Sequence Number, CGA Parameters, and Padding
                  fields) in 8-octet units.
  Pad Length      8-bit unsigned integer. The number of padding
                  octets beyond the end of the CGA Parameters field
                  but within the length specified by the Length
                  field.
  Reserved        An 8-bit field reserved for future use.  The value
                  MUST be initialized to zero by the sender and MUST
                  be ignored by the receiver.
  Sequence Number 32-bit unsigned integer. If the CGA Params
                  option was sent in response to a CGA Request,
                  this field matches he sequence number in the
                  request.  Otherwise, it SHOULD be set to zero.
  CGA Parameters  A variable-length field containing the CGA
                  Parameters data structure described in Section 2
                  of [RFC3972].
  Padding         A variable-length field making the option length a
                  multiple of 8, containing as many octets as
                  specified in the Pad Length field. The contents of
                  padding MUST be set to zero on sending and
                  ignored on receipt.

6.3.  CGA Signature

The CGA Signature option contains the digital signature calculated by he sender. It is formatted as follows:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |    Length     |   Pad Length  |    Reserved   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  .                                                               .
  .                       Signature                               .
  .                                                               .
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  .                           Padding                             .
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Type            8-bit unsigned integer. Type code for CGA
                  Signature. The value is TBD4.
  Length          The length of the option (including the Type,
                  Length, Pad Length, Reserved, Sequence Number, CGA
                  Signature, and Padding fields) in units of 8-octets.
  Pad Length      8-bit unsigned integer. The number of padding
                  octets beyond the end of the CGA Signature field
                  but within the length specified by the Length field.
  Reserved        8-bit unsigned integer. An 8-bit field reserved for
                  future use. The value MUST be initialized to zero
                  by the sender and MUST be ignored by the receiver.
  Signature       A variable-length field containing the signature
                  which is produced by the private-key.
  Padding         A variable-length field making the option length a
                  multiple of 8, containing as many octets as
                  specified in the Pad Length field.  The contents
                  MUST be set to zero when sending and MUST be
                  ignored on receipt.

7.  Packet Processing

This section describes how CGA Extension Headers are generated and processed.

7.1.  Sending a CGA Request

To send a CGA Request packet, the host generates a new Sequence Number, and formats the packet as described in section 3.1.

7.2.  Receiving a CGA Request

When a host receives a packet containing a CGA Request, it MAY send CGA Params and CGA Signature to its peer as a response. Whether or not to send a response is determined by local policy or configuration.

If the host responds to the CGA Request, it must set the Sequence Number of the CGA Params option to the Sequence Number received in the CGA Request.

7.3.  Sending CGA Params

The CGA parameters should be generated using the procedure defined in Section 4 of [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.). The public key carried in the CGA Params must correspond to the private key used to generate the digital signature.

7.4.  Sending a CGA Signature

When sending a CGA Signature, the host must calculate the digital signature value using the procedure described here.

The contents to be signed contain the following parts concatenated from left to right:

1. The CGA Extension Header signature type tag (128-bits);
2. The 128-bit source address in the IP header;
3. The 128-bit destination address in the IP header;
4. All parts of CGA Extension Header except the CGA Signature;
5. The payload of the packet (transport and higher layers).

The resulting data is signed using an RSA signature, and the signature is placed in the Signature field. The signature is generated largely as described in [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) section 5.2. TBD: Need to describe the procedure in detail and specify a signature type tag for the CGA Extension Header here. Pick up algorithm agility work from CSI?

7.5.  Receiving CGA Params and CGA Signature

After the host receives the packet with CGA Params and CGA Signature, it MAY verify the signature, thus authenticating the source CGA. Whether or not the host performs the verification procedure on a specific packet is based on policy and/or configuration. The verification procedure consists of the following steps:

1. If a host receives a packet corresponding to an outstanding CGA Request, it checks if the Sequence Number is zero (meaning this is not a response). If so, it continues to the next step. If the Sequence number is non-zero, it compares the received Sequence Number with the Sequence Numbers of recently sent CGA Requests. If the Sequence Number matches a previous request, go to the next step. Otherwise, the host MUST drop the packet and send an ICMP message.
2. The host MAY use the CGA parameters and signature to verify the source CGA of the packet. The verification procedure is given in Section 5 of [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.). If the verification succeeds, go to the next step. Otherwise, the host MUST drop the packet, which leads to the generation of an ICMP message.
3. The inputs of the signature verification operation are the public key, which is a part of the CGA parameters data structure, the concatenation created in Section 3.1 and the signature. If the signature verification succeeds, the host should continue to process the packet as usual. If it fails, the host MUST drop the packet and send an ICMP message.

Certain errors MAY result in dropping the packet and sending ICMP messages:

1. The CGA header contains only CGA Params rather than CGA Signature;
2. The CGA header contains only CGA Signature rather than CGA Params;
3. The host sends the CGA Request, however, the returned packet does not contain CGA Params and CGA Signature.

8.  ICMP Messages

TBD: ICMP errors and related behavior will need to be defined in more detail.

When the CGA header of IPv6 is deployed and certain errors occur, ICMP messages are required to report errors to the source host. In addition to the problems described in [RFC4443] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.), CGA header has following types of errors.

8.1.  Verification Failure

Verification failure MAY be caused by the following:

1. Sequence Number error;
2. CGA verification error;
3. Signature verification error.

8.2.  Option Errors

The three type option errors described at the end of Section 4.2 also MAY generate ICMP messages.

9.  Source Address Verification

This mechanism supports both one-way and bi-directional verification. In this section, we denote the two ends of the verification process as the Initiator and the Responder, and we present all three verification scenarios.

9.1.  Initiator Verifying Responder’s Address

The following picture shows a typical exchange when the initiator verifies the address of the responder.

         Initiator                              Responder

                           CGA Request
                   -------------------------->

                       CGA Params, CGA Sig
                   <-------------------------

The initiator sends CGA Request in the message to require the CGA parameters of the responder. After receiving the request, the responder returns its own CGA Params and CGA Signature to the initiator. The processing rules and verification process are given in Section 4.1 and Section 4.2 respectively.

9.2.  Responder Verifying Initiator’s Address

The responder can also verify the address of the initiator. Conceptually, the process can be represented by the following message sequence.

         Initiator                              Responder

                         NULL CGA HEADER
                   -------------------------->

                           CGA Request
                   <-------------------------

                       CGA Params, CGA Sig
                   -------------------------->

A packet with a NULL CGA Extension Header coming from the initiator implies that the initiator may support CGA verification. After receiving the null CGA Extension Header, the responder sends a CGA Request to the initiator. Then the initiator sends its CGA Params and CGA Signature in a response, which is used to verify the initiator's address by the responder.

9.3.  Bidirectional Verification

In certain cases, the hosts need to verify the address of each other. The figure below illustrates the basic exchange.

         Initiator                              Responder

                         NULL CGA HEADER
                   -------------------------->

                           CGA Request
                   <-------------------------

                  CGA Params, CGA Sig, CGA Request
                   -------------------------->

                        CGA Params, CGA Sig,
                   <-------------------------

A packet with null CGA Extension Header coming from the initiator implies that the sender may support CGA verification. After receiving the NULL CGA Extension Header in the message, the responder sends CGA Request to the initiator. Then the initiator transfers the message containing its CGA Params, CGA Signature and CGA Request. The last message with CGA Params and CGA Signature of the responder is to allow the initiator to verify the responder's address.

10.  Discussion

There are a number of architectural issues and tradeoffs in the design of this mechanism that might benefit from further discussion and consideration. This section attempt to outline those issues at a fairly high level in the hope of generating discussion within the IETF on these topics:

10.1.  MTU and Fragmentation Issues

As this document is currently written, the CGA Fragmentation Header appears after the IPv6 Fragment Header. This allows us to avoid MTU issues, because a long CGA Extension Header would be fragmented, as necessary, to fit on the link. However, it means that intermediate nodes are not guaranteed to see a full CGA Extension Header, potentially limiting the use cases of this mechanism. If there is interest in this approach, we should further discuss these tradeoffs.

10.2.  Strength of Security

As discussed in Section 7.2 of RFC 3972, an attacker has to do 2**59 times as much work as the holder of a CGA in order to forge a given CGA. This may provide inadequate security for many potential uses of this mechanism.

There are some approaches that could be used to increase the security strength of CGAs. For instance, it might be possible to increase the length of the cryptographically-generated portion of the CGA, in cases where the prefix length allow sufficient room to do so. It might also be possible for higher-level protocols to introduce additional bits of security into the algorithm. Work on these, or other, approaches to increase the security of this mechanism could be considered if there is interest in the general approach.

10.3.  Costs of Verification

Generating and verifying the digital signatures are both high cost operations. The costs of generating and/or verifying the source CGA of every packet would make this mechanism too costly for many applications. The mechanism includes the a method to explicitly request this information, but there is no guidance on when/how to use it.

It might be possible to use this mechanism in concert with another, lower costs security mechanism. For example, the CGA Extension Header could be used to verify that the remote node owns a particular CGA before using that CGA to determine and IPsec SA that will be used to protect the rest of the session.

The ability for a remote host to prompt a costly operation in a local host by sending a single packet represents a potential DoS attack. We might want to consider a preliminary challenge/response operation or some other mechanism to ensure that prompting this operation in a local host requires at least as much processing by the remote host.

11.  Security Considerations

This specification defines a mechanism to use CGAs for access control. The RSA signature in a packet can be used to confirm that the packet is generated by the holder of the private key associated with the CGA. If a resource is authorized to a CGA and the signature is checked, then the node providing the resource has confidence that the resource is being accessed by the holder of the CGA. Implementations MUST provide a mechanism for indicating which addresses require signatures and signature verification. The security of authorization depends critically on the correct usage of this mechanism. If an address is added to an access-control list but not to the list of addresses requiring signature verification, then an attacker may gain access to the protected resource by spoofing this address.

Unlike a traditional IP-based access-control list, this mechanism does not permit ranges of IP addresses. An attacker could potentially generate an address within a given range and legitimate users are unlikely to have addresses in any given range. For this reason, security depends on authorizing each address separately.

As discussed in Section 7.2 of RFC 3972, an attacker has to do 2**59 times as much work as the holder of a CGA in order to forge a given CGA. The work can be increased for an attacker at the expense of making address generation harder for legitimate users. For some applications, the work factor of 2**59 address generations to forge a given address may provide insufficient security. The CGA extension header is not a good approach for these applications.

Section 7.4 of RFC 3972 discusses security concerns when CGAs are used for protocols other than SEND. Of particular note, RSA keys of 384-bits are inappropriate for the CGA extension header. Keys of at least 2048-bits in length SHOULD be used.

This mechanism only secures access-control based on IP address. If another insecure mechanism is used to determine authorized source addresses, then attacks on that mechanism result in attacks on the authorization. For example if DNS is used to lookup the addresses of nodes to populate an access-control list, then attacks on the integrity of DNS will result in attacks of the security of this mechanism used along-side DNS.

CGA extension header signatures can be expensive to verify. Understanding how to prevent denial of service attacks against the CGA header mechanism is ongoing work.

12.  IANA Considerations

This document specifies a new type of IPv6 extension header, whose value is to be allocated:

      Value Next Header Name Reference
      ------  -------------------------------  ---------
      TBD1    CGA Header                       [this doc]

This document defines three new options in the CGA Header. A new namespace is required to be assigned by IANA and the values of these options are to be allocated:

      Value   Option Name                      Reference
      ------  -------------------------------  ---------
      TBD2    CGA Request                      [this doc]
      TBD3    CGA Params                       [this doc]
      TBD4    CGA Signature                    [this doc]

The above assignation of the three CGA options SHOULD also be used in destination extension header and identified by the any host.

This document also defines two new types of ICMP messages whose values are to be allocated from the namespace of ICMP Type Numbers:

      Value   Name                             Reference
      ------  -------------------------------  ---------
      TBD5    Verification Failure             [this doc]
      TBD6    Option Errors                    [this doc]

13.  Acknowledgements

The authors would like to thank the following people for their contributions to this document: Sam Hartman.

Margaret Wasserman's contributions to this document were funded by Huawei Symantec.

14.  References

14.1. Normative References

14.2. Informative References

Authors' Addresses