One document matched: draft-dong-savi-cga-header-03.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3704 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3704.xml'>
<!ENTITY rfc3971 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml'>
<!ENTITY rfc3972 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml'>
<!ENTITY rfc2460 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml'>
<!ENTITY rfc4443 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml'>
]/>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<?rfc rfcedstyle="yes"?>
<rfc ipr='pre5378Trust200902' docName='draft-dong-savi-cga-header-03.txt' category='std'>
<front>
<title abbrev="IPv6 CGA Extension Header">Cryptographically Generated Address (CGA) Extension Header for Internet Protocol version 6 (IPv6)</title>
<author initials='D.' surname='Zhang' fullname='Dong Zhang'>
<organization>Huawei Symantec</organization>
<address>
<postal>
<street>3rd Floor,Section D, Keshi Building, No.28, Xinxi Rd., Shangdi</street>
<city>HaiDian district, Beijing</city>
<!--<region></region>-->
<country>China</country>
</postal>
<phone>+86-10-62721287</phone>
<email>zhangdong_rh@huaweisymantec.com</email>
</address>
</author>
<author initials='P.' surname='Nallur' fullname='Padmanabha Nallur'>
<organization>Huawei Symantec</organization>
<address>
<postal>
<street>20245 Stevens Creek Blvd., Suite 100</street>
<city>Cupertino</city>
<region>California</region>
<country>USA</country>
</postal>
<email>paddy@huaweisymantec.com</email>
</address>
</author>
<author initials='M.' surname='Wasserman' fullname='Margaret Wasserman'>
<organization>Painless Security</organization>
<address>
<postal>
<street>356 Abbott Street</street>
<city>North Andover</city>
<region>MA</region>
<country>USA</country>
</postal>
<phone>+1-781-405-7464</phone>
<email>mrw@painless-security.com</email>
</address>
</author>
<date year='2010' month="July" />
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<keyword>CGA</keyword>
<keyword>Cryptographically Generated Addresses</keyword>
<keyword>IPv6</keyword>
<keyword>Internet Protocol Version 6</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
A Cryptographically Generated Address (CGA) is an IPv6 address that
has been generated using a cryptographic key
<xref target="RFC3972"/>. CGAs were originally designed for use in the
SEcure Neighbor Discovery (SEND) protocol <xref target="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.
</t>
<t>
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.
</t>
</section>
<section title="Requirements Terminology">
<t>
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
<xref target="RFC2119"/>.
</t>
</section>
<section title="Secure Node-Based Access Control">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<section title="Use Cases">
<t>
Some example use cases for the CGA Extension Header include:
<list style="symbols">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
<t>
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.
</t>
</section>
</section>
<section title="Issues with the CGA Extension Header">
<t>
The CGA Extension Header mechanism does have a few limitations that
affect its applicability in some cases. Specifically:
<list style="symbols">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
<t>
Some ideas about how to address the above issues are discussed in the
"Discussion" section below.
</t>
</section>
<section title='CGA Extension Header Definition'>
<t>
The base IPv6 specification <xref target="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.
</t>
<t>
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:
<list style='hanging'>
<t>Hop-by-Hop Options Header</t>
<t>Destination Options Header</t>
<t>Routing Header</t>
<t>Fragment Header</t>
<t>CGA Extension Header</t>
<t>Authentication Header</t>
<t>Encapsulating Security Payload Header</t>
<t>Destination Options Header</t>
<t>Upper-Layer Header</t>
</list>
</t>
<t>
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.
</t>
<t>
The CGA Extension Header MUST NOT be displayed in the extension header of a
packet more than once.
</t>
<t>
The CGA Extension Header is comprised of the following fields:
</t>
<figure>
<artwork>
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].
</artwork>
</figure>
<t>
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.
</t>
</section>
<section title="CGA Options">
<section title='CGA Request'>
<t>
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:
</t>
<figure>
<artwork>
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.
</artwork>
</figure>
</section>
<section title='CGA Params'>
<t>
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:
</t>
<figure>
<artwork>
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.
</artwork>
</figure>
</section>
<section title='CGA Signature'>
<t>
The CGA Signature option contains the digital signature calculated
by he sender. It is formatted as follows:
</t>
<figure>
<artwork>
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.
</artwork>
</figure>
</section>
</section>
<section title='Packet Processing'>
<t>
This section describes how CGA Extension Headers are generated and
processed.
</t>
<section title="Sending a CGA Request">
<t>
To send a CGA Request packet, the host generates a new Sequence
Number, and formats the packet as described in section 3.1.
</t>
</section>
<section title="Receiving a CGA Request">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Sending CGA Params">
<t>
The CGA parameters should be generated using the procedure defined in
Section 4 of <xref target="RFC3972" ></xref>. The public key carried
in the CGA Params must correspond to the private key used to generate
the digital signature.
</t>
</section>
<section title="Sending a CGA Signature">
<t>
When sending a CGA Signature, the host must calculate the digital
signature value using the procedure described here.
</t>
<t>
The contents to be signed contain the following parts concatenated
from left to right:
<list style="numbers">
<t>The CGA Extension Header signature type tag (128-bits);</t>
<t>The 128-bit source address in the IP header;</t>
<t>The 128-bit destination address in the IP header;</t>
<t>All parts of CGA Extension Header except the CGA Signature;</t>
<t>The payload of the packet (transport and higher layers).</t>
</list>
</t>
<t>
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 <xref target="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?
</t>
</section>
<section title="Receiving CGA Params and CGA Signature">
<t>
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:
<list style="numbers">
<t>
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.
</t>
<t>
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 <xref target="RFC3972"></xref>. 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.
</t>
<t>
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.
</t>
</list>
</t>
<t>
Certain errors MAY result in dropping the packet and sending ICMP messages:
<list style="numbers">
<t>The CGA header contains only CGA Params rather than CGA Signature;</t>
<t>The CGA header contains only CGA Signature rather than CGA Params;</t>
<t>The host sends the CGA Request, however, the returned packet does not
contain CGA Params and CGA Signature.</t>
</list>
</t>
</section>
</section>
<section title='ICMP Messages'>
<t>
TBD: ICMP errors and related behavior will need to be defined in more detail.
</t>
<t>
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 <xref target="RFC4443"></xref>, CGA
header has following types of errors.
</t>
<section title='Verification Failure'>
<t>Verification failure MAY be caused by the following:
<list style='numbers'>
<t>Sequence Number error;</t>
<t>CGA verification error;</t>
<t>Signature verification error.</t>
</list>
</t>
</section>
<section title='Option Errors'>
<t>
The three type option errors described at the end of Section 4.2 also MAY generate ICMP messages.
</t>
</section>
</section>
<section title='Source Address Verification'>
<t>
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.
</t>
<section title='Initiator Verifying Responder’s Address'>
<t>
The following picture shows a typical exchange when the initiator
verifies the address of the responder.
</t>
<figure>
<artwork>
Initiator Responder
CGA Request
-------------------------->
CGA Params, CGA Sig
<-------------------------
</artwork>
</figure>
<t>
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.
</t>
</section>
<section title='Responder Verifying Initiator’s Address'>
<t>
The responder can also verify the address of the
initiator. Conceptually, the process can be represented by the
following message sequence.
</t>
<figure>
<artwork>
Initiator Responder
NULL CGA HEADER
-------------------------->
CGA Request
<-------------------------
CGA Params, CGA Sig
-------------------------->
</artwork>
</figure>
<t>
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.
</t>
</section>
<section title='Bidirectional Verification'>
<t>
In certain cases, the hosts need to verify the address of each
other. The figure below illustrates the basic exchange.
</t>
<figure>
<artwork>
Initiator Responder
NULL CGA HEADER
-------------------------->
CGA Request
<-------------------------
CGA Params, CGA Sig, CGA Request
-------------------------->
CGA Params, CGA Sig,
<-------------------------
</artwork>
</figure>
<t>
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.
</t>
</section>
</section>
<section title="Discussion">
<t>
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:
</t>
<section title="MTU and Fragmentation Issues">
<t>
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.
</t>
</section>
<section title="Strength of Security">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Costs of Verification">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title='IANA Considerations'>
<t>
This document specifies a new type of IPv6 extension header, whose
value is to be allocated:
</t>
<figure>
<artwork>
Value Next Header Name Reference
------ ------------------------------- ---------
TBD1 CGA Header [this doc]
</artwork>
</figure>
<t>
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:
</t>
<figure>
<artwork>
Value Option Name Reference
------ ------------------------------- ---------
TBD2 CGA Request [this doc]
TBD3 CGA Params [this doc]
TBD4 CGA Signature [this doc]
</artwork>
</figure>
<t>
The above assignation of the three CGA options SHOULD also be used in
destination extension header and identified by the any host.
</t>
<t>
This document also defines two new types of ICMP messages whose values
are to be allocated from the namespace of ICMP Type Numbers:
</t>
<figure>
<artwork>
Value Name Reference
------ ------------------------------- ---------
TBD5 Verification Failure [this doc]
TBD6 Option Errors [this doc]
</artwork>
</figure>
</section>
<section title='Acknowledgements'>
<t>
The authors would like to thank the following people for their
contributions to this document: Sam Hartman.
</t>
<t>
Margaret Wasserman's contributions to this document were funded by
Huawei Symantec.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc3972;
&rfc2460;
&rfc4443;
</references>
<references title='Informative References'>
&rfc3704;
&rfc3971;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:13:02 |