One document matched: draft-dong-savi-cga-header-02.txt
Differences from draft-dong-savi-cga-header-01.txt
Network Working Group D. Zhang
Internet-Draft Huawei Symantec
Intended status: Standards Track P. Nallur
Expires: December 29, 2009 Futurewei Technologies
June 27, 2009
CGA Extension Header of IPv6
draft-dong-savi-cga-header-02.txt
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 29, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang & Nallur Expires December 29, 2009 [Page 1]
Internet-Draft CGA Extension Header of IPv6 June 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document specifies a method to carry Cryptographically Generated
Addresses (CGA) information in an IPv6 extension header to protect
the IPv6 network from address spoofing.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases Description . . . . . . . . . . . . . . . . . . . . 3
4. Define A CGA Header . . . . . . . . . . . . . . . . . . . . . 5
5. CGA Information . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. CGA Request . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. CGA Params . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. CGA Signature . . . . . . . . . . . . . . . . . . . . . . 8
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Processing Outgoing Packet . . . . . . . . . . . . . . . . 9
6.2. Processing Incoming Packet . . . . . . . . . . . . . . . . 10
7. ICMP Message . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Verification Failure . . . . . . . . . . . . . . . . . . . 11
7.2. Option Errors . . . . . . . . . . . . . . . . . . . . . . 11
8. Source Address Verification . . . . . . . . . . . . . . . . . 11
8.1. Initiator Verifying Resopnder's Address . . . . . . . . . 12
8.2. Responder Verifying Initiator's Address . . . . . . . . . 12
8.3. Bidirectional Verification . . . . . . . . . . . . . . . . 13
9. Using the Destination Options Header to Take CGA
Information . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Zhang & Nallur Expires December 29, 2009 [Page 2]
Internet-Draft CGA Extension Header of IPv6 June 2009
1. Introduction
The CGA specifies a new method of generating an IPv6 address with a
cryptographic public key [RFC3972]. This CGA is designed for SEcure
Neighbor Discovery (SEND) protocol [RFC3971]. The original purpose
of using CGA is to verify the messages of the SEND protocol signed by
the address owners without additional security infrastructure.
This document specifies a method to carry Cryptographically Generated
Addresses (CGA) information in an IPv6 extension header to protect
the IPv6 network from address spoofing. This document specifies the
details of CGA parameters, methods to carry them in an IPv6 packet,
proposes verification procedures to validate the packets under
several different situations.
Note that the verification procedure described here is mainly for
illustrating the overall CGA solution. The verification procedure of
illustration of the overall CGA solution. The verification procedure
can be implemented in conjunction with higher layer protocols and not
restricted to a specific protocol layer. Basically the CGA solution
is not a feature of a particular protocol layer but instead can be
used as a general solution for network infrastructure.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Use Cases Description
The CGA solution stated in the later sections fully takes advantage
of the merits of CGA. Every packet is signed by the originator. In
every packet, all information to verify the signature is self-
contained. There is no need to communicate separately with the
sender in order to obtain any parameter to verify the signature in a
received packet. Any node in the network all the way to the
destination is able to validate the packet. Some examples of use
cases for the CGA solution is provided below:
o In mobile wireless networks, the use of radio spectrum is more
expensive. In such networks, the edge node that interfaces
between radio side and the wireline network can verify the
signature in a packet. The packets received from the network side
destined to a mobile user can be filtered by the edge node thus
saving the expensive 'radio resources'. The advantage of using
the CGA solution is that this is implemented at the IP layer and
is applicable to all wireless technologies (GSM, CDMA etc.,).
Zhang & Nallur Expires December 29, 2009 [Page 3]
Internet-Draft CGA Extension Header of IPv6 June 2009
o In enterprise and service provider networks, the network devices
(e.g., routers, switches) communicate with authentication servers,
billing servers and audit servers using specific protocols (e.g.,
RADIUS). The RADIUS protocol for example, normally authenticates
the peer entities using a password mechanism. The password
mechanism is very cumbersome to maintain and operators end up
using same password in many devices. The CGA solution is more
robust and since it is implemented at the IP layer, such a
solution is equally applicable to other protocols (e.g.,
DIAMETER).
o The end users generally trust their network. They hope who they
make connection with all are right parties and may require the
ability of judging the reality of their peers connected. However,
they have no way of knowing whether a packet is forged unless they
are using end-to-end security protocols. The CGA solution does
not involve the complex key management and key distribution
protocols that these end-to-end security protocols require.
o CGA information can be used to help in providing non-repudation
capability from a sender perspective. As an example, one way of
providing non-repudation for an IP packet is to have a user (or a
URL of a website) to IP address association and then followed by
IP address validation. The CGA proposal can be used in providing
the latter functionality. For example, a website can advertise
non-repudiation capability by including CGA information with each
packet that it sends. This can encourage the end users to access
such websites more frequently. The users are more likely to go to
such websites as opposed to the ones that do not provide CGA
information. This can become a selling point for such servers.
o With CGA solution, the routers which implement Ingress Filtering
[BCP38] can perform an additional check for forging before
installing the bindings for the specific IP addresses. The
routers also are capable of optionally authenticating each packet
before it is injected into the rest of the network.
o Billing is one of the functions for ISP. Per-packet billing
without sender non-repudiation would be very difficult. Because
it is easy to spoof, per-packet billing is not quite feasible.
The CGA solution provides a method for sender non-repudiation.
This enables per packet billing services for an application.
o The discovery protocols like SEND etc., implement CGA at the
application layer. If this capability is implemented at IP layer,
then it can be applied to many other discovery protocols (e.g., in
the wireless domain) with minimal changes in the application layer
(e.g., configure the source IP addresses that should be
Zhang & Nallur Expires December 29, 2009 [Page 4]
Internet-Draft CGA Extension Header of IPv6 June 2009
authenticated). The CGA solution implements this functionality at
a lower layer and hence provides the capability that can be used
several applications.
o The multicast packets are used in a variety of applications like
video streaming, IP TV etc. The CGA solution is applicable to the
multicast packets also. The multicast replication devices in the
network can verify the sender of the packet before performing
replication function. If the validation is not successful, the
packet can be dropped thus avoiding the flooding of invalid
packets.
In general, the IP address verification is largely an authentication
function (this address is authentic), while the user-to-address
binding can be an authentication function (this IP address is an
authentic representation of user X) and an authorization function
(user X is authorized to use this IP address - which might have been
DHCP-assigned by an ISP). Depending on the environment,
cryptographic binding between the IP address verification step and
the application authentication/authorization steps might be needed to
securely and effectively use the CGA solution in several of the uses
cases mentioned above.
4. Define A CGA Header
According to [RFC2460], the extension headers of IPv6 are subject to
the ordering recommendations. Of all of the extension headers, the
ones which are handled by network equipments SHOULD occur before
those handled by end-points. After the CGA header is added, a full
implementation of IPv6 includes the following extension headers:
Hop-by-Hop Options header
Destination Options header
Routing header
Fragment header
CGA header
Authentication header
Encapsulating Security Payload header
Zhang & Nallur Expires December 29, 2009 [Page 5]
Internet-Draft CGA Extension Header of IPv6 June 2009
Destination Options header
upper-layer header
The CGA header MUST NOT be displayed in the extension header of a
packet more than once.
The CGA header is used to carry optional information. A responder
either authenticates the address of the initiator based on the CGA
information or sends his own CGA options to the initiator. The CGA
header is identified by a Next Header value of TBD1 in IPv6 header.
The format of the CGA header is described 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header
immediately following the CGA header.
Hdr Ext Len 8-bit unsigned integer. Length of the CGA 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.
If one host wants to protect the communication,
it will send the CGA header of which Hdr Ext Len
is zero. After receiving the preceding type of
the CGA header, an end-point sends a CGA Request
as a response.
Reserved An 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, of length such that the
complete CGA header is an integer multiple of 8
octets long. Contains one or more TLV-encoded
options, as described in section 4.2 of [RFC2460].
The Options field contains three types of data: CGA Request, CGA
Params and CGA Signature. CGA Request is used to ask the counterpart
for CGA Params; CGA Params is used to carry a CGA parameters data
structure; CGA Signature contains the signature produced by the host
using its private key. CGA Params MUST be accompanied with CGA
Zhang & Nallur Expires December 29, 2009 [Page 6]
Internet-Draft CGA Extension Header of IPv6 June 2009
Signature. Otherwise the receiver SHOULD respond with an ICMP
message. The packets 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.
5. CGA Information
5.1. CGA Request
Any node can ask its peer for CGA Params by sending CGA Request in
the packet. The node that receives the packet with CGA Request, MAY
respond with its own CGA Params and CGA Signature. CGA Request is of
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.
Sequence Number 32-bit unsigned integer. Random-number. It contains
a counter value that increases by one for each
packet sent. It may enable the anti-replay service.
5.2. CGA Params
This type data of the options carries CGA parameters according to
which the receiver validates the address. The format of the CGA
Params is described in the following diagram:
Zhang & Nallur Expires December 29, 2009 [Page 7]
Internet-Draft CGA Extension Header of IPv6 June 2009
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-octec units of byte.
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 in byte. Padding octets MUST be set to zero
by senders and ignored by receivers.
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. As a response, its value
is to add one to the Sequence Number which belongs
to CGA Request. Otherwise it is 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 zero.
5.3. CGA Signature
This type data of the options is responsible for carrying the
signature. In particular, the following illustration shows the
format of CGA Signature:
Zhang & Nallur Expires December 29, 2009 [Page 8]
Internet-Draft CGA Extension Header of IPv6 June 2009
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Digital 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 byte.
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
in byte. Padding octets MUST be set to zero by
senders and ignored by receivers.
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.
Digital 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.
6. Packet Processing
To send a CGA Request packet, the host generates a 32-bit random
Sequence Number, and formats the packet as described in section 3.1.
Once a host receives the packet with CGA Request, it MAY either
respond with a CGA Params or ignore the packet according to the
host's policy.
6.1. Processing Outgoing Packet
When a host finds CGA Request in the extension header of the packet,
it MAY send CGA Params and CGA Signature to its peer as a response.
In addition, the host also MAY send CGA Params and CGA Signature,
which depends on the higher layer protocols.
Zhang & Nallur Expires December 29, 2009 [Page 9]
Internet-Draft CGA Extension Header of IPv6 June 2009
If the host responds to CGA Request, its Sequence Number MUST be
equal to the Sequence Number of the CGA request plus one. When the
host sends CGA Params and CGA Signature actively, the Sequence Number
SHOULD be set to zero in CGA Params.
CGA parameters generation is illustrated in Section 4 of [RFC3972].
The private key used to make the Digital Signature part in CGA
Signature MUST correspond to the public key carried in the CGA
parameters part of CGA Params. The contents to be signed contain the
following parts concatenated from left to right:
1. 128-bit source address in the IP header;
2. 128-bit destination address in the IP header;
3. All parts of CGA header except CGA Signature;
4. Payload of the packet (transport and higher layers).
The data obtained is signed through the RSA method and the signature
is placed in the Digital Signature field.
6.2. Processing Incoming Packet
After the host receives the packet with CGA Params and CGA Signature,
either can it make an authentication with parameters and signature or
ignore them, which depends on the higher layers. If the host need
authentication, the procedure is as follows:
1. If a host receives a responding packet to CGA Request, it
compares the received number with the Sequence Number in CGA
Request sent earlier. If the received number is greater and
within the a specified window size than the number sent in the
CGA request, then go to the next step. Otherwise, the host MUST
drop the packet, which leads to the generation of an ICMP
message.
2. On the basis of CGA parameters, the host MAY verify the source
address in IP header. 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, go on other extension headers
Zhang & Nallur Expires December 29, 2009 [Page 10]
Internet-Draft CGA Extension Header of IPv6 June 2009
processing or pass the IP payload to upper layer. Otherwise, the
host MUST drop the packet which leads to the generation of an
ICMP message.
Certain errors also 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 return.
7. ICMP Message
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.
7.1. Verification Failure
Verification failure MAY be caused by the following:
1. Sequence Number error;
2. CGA verification error;
3. Signature verification error.
7.2. Option Errors
The three type option errors described at the end of Section 4.2 also
MAY generate ICMP messages.
8. Source Address Verification
Sometimes it is appreciated to do one-way authentication. For
example, host A intends to build a connection with host B. If host A
suspects the identity of the responder, host A MAY ask for
verification. Perhaps this scenario occurs in the Client/Server
model. When both hosts of one connection need to confirm the
identities of each other, they do bidirectional verification.
In this section, the processes of three types of verification
Zhang & Nallur Expires December 29, 2009 [Page 11]
Internet-Draft CGA Extension Header of IPv6 June 2009
applications are presented. In the connection of two hosts, one is
denoted with Initiator and the other with Responder.
8.1. Initiator Verifying Resopnder'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.
8.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 null CGA header coming from the initiator implicates
that there may be a CGA verification process. After receiving this
kind of special CGA header in the message, the responder sends CGA
Request to the initiator. Then the initiator transfers its CGA
Params and CGA Signature as response, which is used to verify the
initiator's address by the responder.
Zhang & Nallur Expires December 29, 2009 [Page 12]
Internet-Draft CGA Extension Header of IPv6 June 2009
8.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 header coming from the initiator implicate
that there may be a CGA verification process. After receiving this
kind of special CGA 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 address.
9. Using the Destination Options Header to Take CGA Information
As an alternative to creating a new IPv6 header, the existing
extension header can also be modified to carry the CGA information.
This is further explored in this section.
It is articulated that a full implementation of IPv6 includes six
types of extension header in [RFC2460]. From the definition of the
extension headers, it can be easily inferred that the destination
options header is the optimal choice. The three types of options
defined in section 3, including CGA Request, CGA Params and CGA
Signature, SHOULD be put in the options field of the destination
options header within the packets wherever the source address
protection is need.
In the implementation of IPv6, destination options header is able to
occur in different place and twice (once before a routing header and
once before the upper-layer header) in one packet.
1. The destination header before the routing header is used for
options to be processed by the first destination that appears in
Zhang & Nallur Expires December 29, 2009 [Page 13]
Internet-Draft CGA Extension Header of IPv6 June 2009
the IPv6 Destination Address field plus subsequent destinations
listed in the routing header.
2. The destination header before the upper-layer header is used for
options to be processed only by the final destination of the
packet.
The above feature of destination options header provides the
convenience of the solution using CGA to protect the source address.
If the end host validates the CGA, put the destination options header
with the CGA information options before the upper-layer header. This
usage of the destination options header has the same effect with CGA
extension header. Otherwise, in case 1, any node whose address must
be put in the first place of the routing header can make the
validation of CGA. For instance, put the address of the first-hop
router or gateway in the first place of the routing header, so the
first-hop router or gateway would validate the CGA, which prevents
the forged packets form getting out of their LAN environment.
The advantage of carrying the CGA information in destination options
header is mainly to avoid the problem of modifying the current
protocols.
10. Security Considerations
Address verification and signature verification by the CGA header is
to validate the identity of the host. At the same time, the CGA
header can limit the exposure of the host to man-in-the-middle (MitM)
and some denial-of-service (DoS) attacks. Because the CGA header is
an application in Network Layer, the higher layer protocols MAY
choose this way to protect communication.
The CGA header can prevents MitM attack. MitM forges packets with
great difficulty. Because of the features of CGA, it is impossible
for MitM to make a spoofed private key based on the address
[RFC3972]. Or, at present, the private key cannot be generated
through the corresponding public key. On the other hand, the
Sequence Number and signature in the CGA header are able to prevent
replay attack.
The CGA header can prevent some DoS attacks as well. Since CGA can
not be forged, attackers cannot launch DoS attack with many spoofed
source addresses. If making DoS attack with the real address, the
attacker is easy to be exposed.
In the implement of the CGA header, signing packets consumes a large
amount of resources. When one host receives packets with CGA Request
from a same source address repeatedly, it MUST refuse to return the
Zhang & Nallur Expires December 29, 2009 [Page 14]
Internet-Draft CGA Extension Header of IPv6 June 2009
CGA Params and CGA Signature. The form of DoS attack using CGA
verification process can also be avoided by ignoring the packets.
To avoid the DoS attack of CGA Request, the host MAY choose to ignore
the packets with CGA Request before sending the CGA initial message
whose CGA header length is zero or verifying its peer's CGA Params
and CGA Signature. The choice depends on the policy of the host.
If a host receives CGA Params and CGA Signature from a source address
that does not send the CGA Request, the host cannot trust the source
address. Because there is no Sequence Number preventing replay
attack. In this case, how to handle the packet depends on the local
policy.
11. 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]
12. Acknowledgements
13. References
Zhang & Nallur Expires December 29, 2009 [Page 15]
Internet-Draft CGA Extension Header of IPv6 June 2009
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[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.
13.2. Informative References
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering",
BCP 38, May 2000.
[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
Futurewei Technologies
3255-4, Scott Blvd
Santa Clara, California
USA
EMail: pnallur@huawei.com
Zhang & Nallur Expires December 29, 2009 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 05:46:12 |