One document matched: draft-dong-savi-cga-header-03.txt
Differences from draft-dong-savi-cga-header-02.txt
Network Working Group D. Zhang
Internet-Draft P. Nallur
Intended status: Standards Track Huawei Symantec
Expires: January 13, 2011 M. Wasserman
Painless Security
July 12, 2010
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
Zhang, et al. Expires January 13, 2011 [Page 1]
Internet-Draft IPv6 CGA Extension Header July 2010
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.
Zhang, et al. Expires January 13, 2011 [Page 2]
Internet-Draft IPv6 CGA Extension Header July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4
3. Secure Node-Based Access Control . . . . . . . . . . . . . . . 4
3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Issues with the CGA Extension Header . . . . . . . . . . . . . 6
5. CGA Extension Header Definition . . . . . . . . . . . . . . . 6
6. CGA Options . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. CGA Request . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. CGA Params . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. CGA Signature . . . . . . . . . . . . . . . . . . . . . . 9
7. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Sending a CGA Request . . . . . . . . . . . . . . . . . . 10
7.2. Receiving a CGA Request . . . . . . . . . . . . . . . . . 10
7.3. Sending CGA Params . . . . . . . . . . . . . . . . . . . . 11
7.4. Sending a CGA Signature . . . . . . . . . . . . . . . . . 11
7.5. Receiving CGA Params and CGA Signature . . . . . . . . . . 11
8. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Verification Failure . . . . . . . . . . . . . . . . . . . 12
8.2. Option Errors . . . . . . . . . . . . . . . . . . . . . . 13
9. Source Address Verification . . . . . . . . . . . . . . . . . 13
9.1. Initiator Verifying Responder's Address . . . . . . . . . 13
9.2. Responder Verifying Initiator's Address . . . . . . . . . 13
9.3. Bidirectional Verification . . . . . . . . . . . . . . . . 14
10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . . 15
10.2. Strength of Security . . . . . . . . . . . . . . . . . . . 15
10.3. Costs of Verification . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . . 18
Zhang, et al. Expires January 13, 2011 [Page 3]
Internet-Draft IPv6 CGA Extension Header July 2010
1. Introduction
A Cryptographically Generated Address (CGA) is an IPv6 address that
has been generated using a cryptographic key [RFC3972]. CGAs were
originally designed for use in the SEcure Neighbor Discovery (SEND)
protocol [RFC3971], 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].
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.
Zhang, et al. Expires January 13, 2011 [Page 4]
Internet-Draft IPv6 CGA Extension Header July 2010
3.1. Use Cases
Some example use cases for the CGA Extension Header include:
o 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.
o 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.
o 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.
o 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.
o 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.
o 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.
Zhang, et al. Expires January 13, 2011 [Page 5]
Internet-Draft IPv6 CGA Extension Header July 2010
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:
o 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.
o 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.
o 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] 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
Zhang, et al. Expires January 13, 2011 [Page 6]
Internet-Draft IPv6 CGA Extension Header July 2010
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].
Zhang, et al. Expires January 13, 2011 [Page 7]
Internet-Draft IPv6 CGA Extension Header July 2010
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:
Zhang, et al. Expires January 13, 2011 [Page 8]
Internet-Draft IPv6 CGA Extension Header July 2010
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:
Zhang, et al. Expires January 13, 2011 [Page 9]
Internet-Draft IPv6 CGA Extension Header July 2010
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
Zhang, et al. Expires January 13, 2011 [Page 10]
Internet-Draft IPv6 CGA Extension Header July 2010
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]. 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] 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:
Zhang, et al. Expires January 13, 2011 [Page 11]
Internet-Draft IPv6 CGA Extension Header July 2010
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]. 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], CGA header has
following types of errors.
8.1. Verification Failure
Verification failure MAY be caused by the following:
Zhang, et al. Expires January 13, 2011 [Page 12]
Internet-Draft IPv6 CGA Extension Header July 2010
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.
Zhang, et al. Expires January 13, 2011 [Page 13]
Internet-Draft IPv6 CGA Extension Header July 2010
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.
Zhang, et al. Expires January 13, 2011 [Page 14]
Internet-Draft IPv6 CGA Extension Header July 2010
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.
Zhang, et al. Expires January 13, 2011 [Page 15]
Internet-Draft IPv6 CGA Extension Header July 2010
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.
Zhang, et al. Expires January 13, 2011 [Page 16]
Internet-Draft IPv6 CGA Extension Header July 2010
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Zhang, et al. Expires January 13, 2011 [Page 17]
Internet-Draft IPv6 CGA Extension Header July 2010
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
14.2. Informative References
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Authors' Addresses
Dong Zhang
Huawei Symantec
3rd Floor,Section D, Keshi Building, No.28, Xinxi Rd., Shangdi
HaiDian district, Beijing
China
Phone: +86-10-62721287
EMail: zhangdong_rh@huaweisymantec.com
Padmanabha Nallur
Huawei Symantec
20245 Stevens Creek Blvd., Suite 100
Cupertino, California
USA
EMail: paddy@huaweisymantec.com
Margaret Wasserman
Painless Security
356 Abbott Street
North Andover, MA
USA
Phone: +1-781-405-7464
EMail: mrw@painless-security.com
Zhang, et al. Expires January 13, 2011 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 05:46:33 |