Network Working Group J. Bi
Internet-Draft J. Wu
Intended status: Experimental G. Yao
Expires: January 28, 2009 CERNET
July 27, 2008
A CGA based Source Address Authorization and Authentication (CSA)
Mechanism for First IPv6 Layer-3 Hop
draft-bi-savi-csa-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 28, 2009.
Bi, et al. Expires January 28, 2009 [Page 1]
Internet-Draft draft-bi-savi-csa-00 July 2008
Abstract
This document describes a method to authorize and authenticate the
address of a node in an IPv6 network. Except for "Host Change", this
method satisfies all the requirements in the Charter of SAVI. The
modification on a host can be regarded as the extension of SEND and
IPSec.
Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Address Authorization . . . . . . . . . . . . . . . . . . . . 5
3.1. Address Preparation . . . . . . . . . . . . . . . . . . . 5
3.2. Identifier Generation . . . . . . . . . . . . . . . . . . 7
3.3. Address Request . . . . . . . . . . . . . . . . . . . . . 8
3.4. Gateway Authorizing Address . . . . . . . . . . . . . . . 10
3.5. Address Assignment . . . . . . . . . . . . . . . . . . . . 13
4. Address Authentication . . . . . . . . . . . . . . . . . . . . 14
4.1. Signature Generation . . . . . . . . . . . . . . . . . . . 14
4.2. Signature Addition . . . . . . . . . . . . . . . . . . . . 14
4.3. Sending packet . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Packet Checking by the Router . . . . . . . . . . . . . . 15
4.5. Router Transmitting Packet . . . . . . . . . . . . . . . . 15
5. Some Consideration . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Refresh of the mapping table . . . . . . . . . . . . . . . 16
5.2. Cooperating with SEND . . . . . . . . . . . . . . . . . . 16
5.3. Deployment not on first-hop router . . . . . . . . . . . . 16
5.4. Spoofing Prevention Functionality . . . . . . . . . . . . 16
5.5. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 17
5.6. Other Considerations . . . . . . . . . . . . . . . . . . . 17
6. Comparision with Charter . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Bi, et al. Expires January 28, 2009 [Page 2]
Internet-Draft draft-bi-savi-csa-00 July 2008
1. Requirements Language
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 RFC 2119 [RFC2119].
Bi, et al. Expires January 28, 2009 [Page 3]
Internet-Draft draft-bi-savi-csa-00 July 2008
2. Introduction
In this method, a node must request the right to use an IPv6 address
from the first-hop gateway(either a layer 2 gateway or a layer 3
gateway). The first-hop gateway makes a decision on whether the
address can be used by the node, according to the current address
allocation method. Following an affirmative decision, a secret is
exchanged between the node and the gateway. Whenever the node wants
to send a packet via the gateway, a signature MUST be added into the
packet if required by the gateway. The signature is generated using
the shared secret and both the gateway and the node know the
generating algorithm. The gateway checks the signature to confirm
that the packet is from the owner of the source address. An
identifier called "CGA identifier" is used to help in the address
ownership determination.
When a host is connected to a monopolized port of a switch, the
switch can enable filtering at the port to prevent spoofing packets
from the host easily. However, it may comes that there is no switch
between the host and the router, or more than one hosts share a port
through a hub, or not all the switches in the network can be updated/
replaced to enable filtering. This method is designed to suit in the
situation where it is not possible to perform filtering on the port
of switch. Though it is relatively more complex and the overhead is
higher, this method has good flexibility since it is independent of
the interconnection medium. And generally it is more economical
since it doesn't require replacing all the switches in a network.
This mechanism comprises of two main parts: The address authorization
process and the address authentication process.
Bi, et al. Expires January 28, 2009 [Page 4]
Internet-Draft draft-bi-savi-csa-00 July 2008
3. Address Authorization
This process is shown in the Fig.1.
Node Gateway
| |
| Request Addr A |
Address |---------------->|
Request | Identifier=IA |
| Pub Key=Pk |
| |
| |
| |Address Use Right Check,
| |Binding(IA,Pk,A,Seed)
| |
Address | Comfirm Addr A |
Assignment |<----------------|
| Signature Seed |
| Encypted by Pk |
| |
Figure 1: Address authorization process
3.1. Address Preparation
We emphasize the manner of address assignement since we define IP
spoofing to be taking place when a user/host/interface uses one or
more addresses which are not assigned to it by the appointed
allocation method, or the configuration of an allocated address is
incorrect. IP spoofing caused by erroneous configuration is
generally not malicious and can be corrected easily once the error is
detected. Moreover, if the allocation mechanism is misconfigured,
the spoof filtering mechanism has no way to run correctly since the
information used in filtering will also be incorrect. Thus we only
deal with the use of addresses not allocated to the user/host/
interface by the allocation method.
In this stage, if the node is a host, it MUST prepare an address.
The address MUST be got according to current address allocation
method. In IPv6, this means:
Manually: the address MUST be got from the network administrator.
This means the address is allocated to the host/user/interface by the
administrator.
DHCP(either stateless or stateful): the address MUST be got from the
Bi, et al. Expires January 28, 2009 [Page 5]
Internet-Draft draft-bi-savi-csa-00 July 2008
DHCP server[DHCP,stateful,stateless]. To help affirm which host gets
the ownership of the address returned by the DHCP server, the request
message must be changed to contain an unspoofable host identifier.
We chose CGA[CGA] to play the role of the identifier in preference to
PKI. The procedure of DHCP allocation is changed as follows: The
node MUST use a CGA address as the source address to request an
address from the DHCP server. The CGA address MUST be generated
using the procedure described in [CGA]. The corresponding CGA option
and signature MUST be contained in the packet. The request packet
MUST contain a random nonce to prevent replay attack. The first-hop
layer-3 gateway MUST have the ability of obtaining the request
message and the response message of the DHCP server. The DHCP server
MAY be placed outside of the local network and so the gateway will
forward both kinds of message. Alternatively, these packets MAY be
changed to multicast packets to reach the gateway, or yet other
methods may be chosen here. The gateway MUST check the correctness
of signature and address portion of the request packet, and discard
invalid packets. The gateway MUST record the CGA address in the
validated request packet, and wait for the response packet from the
DHCP server. Once a response message arrives, the gateway will check
which address is allocated to the applicant and bind the CGA address
of the applicant to the allocated address. The advertised address in
the response packet is the address allocated to the host. If there
is any DHCP relay point, the source address of the request packet
MUST be unchanged before it reaches the gateway.
Stateless Autoconfiguration: the address MUST be got using NDP and
there MUST be no duplication[SAC].
Privacy: the address MUST be got using NDP and there MUST be no
duplication[Privacy]. This mechanism doesn't guarantee the privacy
requirement of node. The node MUST use its own policy to achieve
privacy. [Privacy].
CGA: the address MUST be generated according to CGA generation
algorithm[CGA]. The Sec value is decided according to the
requirement of administrator.
An arbitrarily generated address will not be regarded as an illegal
address unless it is forbidden under the rules of the appointed
address allocation method. For example, in the manual configuration
case, if a node uses any address other than its allocated address, it
is spoofing. However, if in the SAC situation, a host can use other
addresses as long as they are not being used by other hosts, even if
no DAD has been performed.
The address preparation stage MAY be combined with the other stages
to simplify the procedure. For example, the DHCP address MAY be
Bi, et al. Expires January 28, 2009 [Page 6]
Internet-Draft draft-bi-savi-csa-00 July 2008
obtained together with the signature seed described in the next
section.
If the node is a NAT gateway, it will prepare one or more addresses.
In all cases, the addresses will be allocated by administrator
manually.
If the node is a DHCP-PD router, it prepares one or more prefixes
instead of one address. The prefixes are obtained using the DHCP-PD
protocol. In all cases these prefixes will be previously configured
by the administrator.
If the node is an IPv4 node, the only different case is DHCP. The
node cannot use a CGA address to send a DHCP solicitation. This can
be solved by using the address as an identifier, but not as a
locator. The CGA address in contained in the packet as an option,
and the host id of the IPv4 address is the hash of the CGA address.
The signature is computed on the whole packet.
Other than for DHCP, there is nothing different from normal address
allocation method in this stage. In manual allocation, we already
know which address has been allocated to whom. Thus the validation
of the ownership of the address must be based on some existing and
fixed knowledge, but not a stateless CGA identifier. In SAC and
similar mechanisms, since there is actually no "allocation"
procedure, a node can get ownership of any address not being used.
We don't care who is using the address. In some case we do care who
is using an address, but this problem is actually out of the scope of
preventing IP spoofing. The solution of tracing the user of an
address requires modification of the SAC protocol.
3.2. Identifier Generation
After preparing an address, a node must request the right to use the
address from the first-hop layer-3 gateway. It tells the gateway
"who I am, and which address I want to use". So there must be a
field in the request packet to show the identity of the applicant,
and the value of the field must be unspoofable. Again we choose CGA
to help generate an identifier of the applicant. In DHCP and SAC
cases, CGA works well. However, in the manual configuration case,
the identifier must be stateful and contain fixed information about
the applicant, because the applicant must tell the gateway that it is
the very person/host that owns the address, but not some random
person/host. In this case stateless CGA generation is not
appropriate. We choose using a shared secret to authenticate the
identity of a node in all manual configuration cases. This means if
one knows a correct shared secret, it will get ownership of the
corresponding address. Thus the shared secret must be protected in
Bi, et al. Expires January 28, 2009 [Page 7]
Internet-Draft draft-bi-savi-csa-00 July 2008
the message exchchange and replay attack must be avoided. Adding
state into CGA generation is one possible way of solving this
problem. For example, the shared secret between the applicant and
the gateway could be combined with the public key and a random nonce
to generate an address. Then the shared secret would not be leaked,
and the gateway can recompute the address to ascertain the
correctness of the secret.
Using CGA as an identifer actually wastes the left-most 64 bits.
However, the form of a CGA address is kept and it can be used for
other purposes. For example, this mechanism can cooperate with the
SEND protocol using the CGA identifier.
The procedure of identifier generation is described as follows:
The node MUST generate an identifier. The identifier is a CGA
address whose left-most 64 bits is the network prefix and the right-
most 64 bits is generated according to [CGA] except for any address
allocation method using manual configuration.
In the case where the address is configured manually, a shared secret
MUST be previously allocated between the node and the gateway. The
shared secret is a bit-string longer than 256 bits(this number is to
be decided in the future). The node MUST generate a random number of
128 bits as a nonce. Then the right-most 64 bits of the identifier
is computed by combining the public key, the shared secret, the nonce
and auxiliary parameters. The shared secret MUST be allocated
manually, but not using any key exchange protocol, since the source
address of the applicant has not yet been authorized.
If a node wants to use another address, it CAN use another public key
and identifier or an existing identifer.
The security of the identifier MUST be guaranteed by the node itself,
which means the public key pair MUST not be leaked. IP spoofing
caused by a deliberate leak will not be stopped by this mechanism.
There MUST be no public key duplication in the same network. The
uniqueness will be checked by the gateway. Once a duplicate public
key is found to generate an identifier, the gateway will return an
error and ask the applicant to use another public key.
3.3. Address Request
After preparing the address and the identifier, a node MUST send a
request packet to the gateway. This packet is an ICMP packet, named
Seed Solicitation. Its format is shown in Fig.2.
Bi, et al. Expires January 28, 2009 [Page 8]
Internet-Draft draft-bi-savi-csa-00 July 2008
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Allocation Method | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Nonce |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ CGA Identifier +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. CGA Option .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. RSA Signature Option .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The format of the Seed Solicitation message
IP Fields:
Source Address: The address prepared in the first stage.
Destination Address: This portion MUST be filled with the IP address
of the first-hop layer-3 gateway.
Hop Limit: 1 or more. Generally 1 is enough, but there may be some
extension in the future. For example, the gateway is not one hop
Bi, et al. Expires January 28, 2009 [Page 9]
Internet-Draft draft-bi-savi-csa-00 July 2008
away from the node, but several hops.
ICMP Fields:
Type: TBD
Code: TBD
Checksum: The ICMP checksum.
Address Allocation Method:
Index of address allocation method, which shows by which method the
applicant gets the address. Now: 1: Manually 2: DHCP 3: SAC 4: CGA
5: NAT 6: DHCP-PD
Prefix Length: Only used in DHCP-PD case. It helps to get the
request prefix.
Nonce: A random number that is used to prevent replay attacks.
CGA Identifier: The identifier generated in the phase of "Identifier
Generation".
Options:
CGA Option: Described in [SeND].
RSA Signature Option: Described in [SeND]. Used to anthenticate the
whole message.
The destination address in the packet is obtained through the RA
message from the router. If the RA message is forged by some other
node deliberately, the node will be deceived. This may cause
information leak and the node may be unable to send packets. Hence
the security of NDP SHOULD be protected. However, even SeND cannot
ensure that the sender of a RA message is actually a router.
However, we think the first-hop gateway has enough information to
know the address of the first-hop router, and it SHOULD filter forged
RA message and prevent forged RA message from reaching any node on
local link.
3.4. Gateway Authorizing Address
In this phase, the gateway checks whether the applicant has the right
to use the requested address. This validation is based on the
knowledge of address allocation. If the address is able to be used
by the applicant, a bit string named "signature seed" will be
Bi, et al. Expires January 28, 2009 [Page 10]
Internet-Draft draft-bi-savi-csa-00 July 2008
returned to he applicant.
Whenever the gateway receives a SS packet, firstly it performs
following checks:
o Check if the CGA identifier of the packet is a valid CGA
identifier corresponding to the CGA option. If not, discard it.
If the address allocation method is manually configuration, the
gateway obtains the shared secret of the request address, and
recomputes the identifier to check whether it is correct.
o Check if the signature in RSA signature option is correct. If
not, discard it.
o Check if either the public key or the CGA identifier duplicates
any already registered public key or CGA identifier. If only the
public key is duplicate, return an ICMP message to ask the
applicant to generate another key pair. If both are duplicate,
check if the nonce is different from the previous entry. If yes,
discard the packet; if no, this may happen for a multi-homing
node, or a node requesting a former address. This situation will
be discussed later.
Then the gateway will check whether the applicant has the right to
use the requested address. Depending on the address allocation
method, the gateway will check different things.
o Manual allocation: Once the packet passes the former check on the
CGA identifier, the shared secret has already been validated. So
no further check is required here.
o DHCP: The address MUST be the one that the DHCP server has
allocated to the applicant owning the same CGA identifier in the
packet. This means the gateway has to perform DHCP snooping to
know the association of address and identifier. This knowledge
has been in the first phase.
o Stateless Auto Configuration: The address MUST not have been
registered in the gateway. This means no one has the right to use
this address yet.
o Privacy: The address MUST have not been registered in the gateway.
o CGA: The address MUST be unique and generated following the
algorithm in [CGA]. If there are other restrictions on generating
a CGA, e.g. the Sec value, they MUST be satisfied.
Once the address is found to be able to be used by the applicant, the
Bi, et al. Expires January 28, 2009 [Page 11]
Internet-Draft draft-bi-savi-csa-00 July 2008
gateway will generate a random number called "signature seed". It is
a bit string of 384 bits and MUST not be the same as any former
signature seed. Then the gateway SHOULD keep an entry in a record
table, which has following elements: Address, signature seed, CGA
identifier, public key, Sec value, nonce. The "signature seed" is
used to perform a lightweight authentication in the future.
Then, a packet will be returned to the applicant. This packet is
called Seed Advertisement(SA) message, and has 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
. .
. Signature Seed .
. .
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ CGA Identifier +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. CGA Option .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. RSA Signature Option .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The format of Seed Advertisement message
Bi, et al. Expires January 28, 2009 [Page 12]
Internet-Draft draft-bi-savi-csa-00 July 2008
IP Fields:
Source Address: The address of the router.
Destination Address: The address requested by the node.
Hop Limit: 1 or more.
ICMP Fields:
Type: TBD
Code: TBD
Checksum: The ICMP checksum.
Signature Seed: The signature seed generated by the gateway. This
seed MUST be encrypted by the public key of the request node.
CGA identifier: The CGA identifier of the gateway.
Options:
CGA Option: Described in [SeND].
RSA Signature Option: Described in [SeND]. Used to anthenticate the
message.
3.5. Address Assignment
A node MUST receive any Seed Advertisement packet whose destination
is the address which it has requested, though the address is not
being used by the node.
When a node receives a Seed Advertisement message, firstly it checks
whether the CGA identifier and the RSA signature are correct. If
either of them is incorrect, discard the packet. Once the node gets
a valid Seed Advertisement message from the gateway, it can use the
request address.
Then the node decrypts the signature seed field to get the signature
seed, using its private key generated in the phase of "identifier
generation".
Bi, et al. Expires January 28, 2009 [Page 13]
Internet-Draft draft-bi-savi-csa-00 July 2008
4. Address Authentication
In the previous stage, a node obtains authorization to use an address
and a shared secret "signature seed" has been exchanged between the
gateway and the node. Then normal packet communication will start.
To authenticate normal packets, a signature must be added into the
packets, and the gateway checks the signature.
After the node gets the signature seed for the requested address, all
the a signature MUST be added to all transmitted and this signature
MUST be checked by the gateway.
4.1. Signature Generation
The host generates signatures from the signature seed to sign
packets. Here we propose three candidate method to generate a
signature.
o HMAC
o Pseudo Random Number Generation
HMAC is a mature algorithm and has been tested in many authentication
mechanisms, such as IPSec. HMAC is robust since it is stateless, but
it is computed across the entirety of each packet, which will limit
the forwarding performance of the router.
Though there have been some commercial products which use Pseudo-
Random Number Generation to generate one-time keys, the dependability
of this algorithm used in packet authentication must be tested
generally. Since it is stateful, it it is impacted by out-of-order
packets and dropped packets. But in perfect network condition, it is
more effective than HMAC as it isn!_t computed on the contents of
packets and the signatures can be generated in advance.
Other signature generation methods can also be used here. The only
requirement is that the signature must change with each packet, to
prevent sniffer and replay attack.
NAT and DHCP-PD routers MUST generate a signature for any packets
they transmit.
4.2. Signature Addition
The signature can be added into the packet in three ways:
1 IPSec Authentication Header: It is mature but may conflict with an
existing AH.
Bi, et al. Expires January 28, 2009 [Page 14]
Internet-Draft draft-bi-savi-csa-00 July 2008
2 A new option header: The signature is added as a new destination
option header, or a new hop-by-hop option header. We have done
similar work when implementing a prototype of SPM.
3 Address Rewrite: This is a new method that we have proposed
recently and its value is still untested. In this method, the
signature is not added into the packet as an IP extension header, but
used to mark the source IP address field. We proposed this method
because we found that the overhead of signature addition and removal
is the bottleneck of the authentication method. These two operations
require memory copy which is computationally expensive. Moreover,
the location of the signature iscostly because the IPv6 header is
chaining- structured. Changing some fixed bits costs less. Because
any field of an IP header has a defined meaning, the safest way is to
change the source address, since it is only used when the receiver
wants to reply. The gateway can set up an inverse index table which
maps signature to address, and if the signature contained in source
address field is exists in the table, it rewrites the source address
into the packet. The rationality of this method is based on a
spatial and dynamic signature space.
NAT and DHCP-PD router MUST add the signature for any packets they
transmit.
4.3. Sending packet
After inserting the signature extension header, the node sends it out
via the link between the gateway and itself.
4.4. Packet Checking by the Router
Whenever the router gets a packet, it will check whether the source
address has been applied for and whether the signature is correct.
Because the router keeps a mapping table from the address to the
seed, it is easy to verify the signature.
4.5. Router Transmitting Packet
If the signature in the packet is found to be correct, the router
will remove the Access Network Authentication Header from the packet
and then transmit it. If the signature is inserted by rewriting the
source address, it will replace the signature with the corresponding
address.
Bi, et al. Expires January 28, 2009 [Page 15]
Internet-Draft draft-bi-savi-csa-00 July 2008
5. Some Consideration
5.1. Refresh of the mapping table
The mapping table of address and signature-seed should be refreshed
periodically to prevent brute-force attack. The router should
periodically send a notification to the host to ask them to update
the signature-seed and generate new signatures. Older signature can
pass the validation for a short period, after which only the new
signature is accepted. In APPA, refresh is not needed, because no
brute-force attack can be effective, and also it is hard to keep
synchronization of the signature if the signature-seed changes.
5.2. Cooperating with SEND
SEND is of great importance to maintain a trust between the host and
the router. Without SEND, the host and the router could be deceived
at the very beginning of the process and all the ensuing steps would
not be insecure. Moreover, the seed exchange process can be designed
as an extension of SEND.
5.3. Deployment not on first-hop router
It happens that some first-hop routers can not be upgraded to perform
this validation. This mechanism can also be deployed on a distant
gateway. The host should know the address of the gateway first, and
then use the same method to get a signature-seed from the gateway.
The basic mechanism is much the same. However, some details need to
be thought through here. For example, the snooping of DHCP messages
may not be possible on a distant gateway may be not possible, and the
gateway must communicate with the DHCP server.
5.4. Spoofing Prevention Functionality
The basic functionality of the method described is that an attacker
can not use any address that has been successfully applied for by
others. This address can be allocated by any method.
This mechanism cannot prevent a host from using a lot of "reasonable"
addresses, Because this behaviour does not differ much from normal
behaviour. But we can limit the frequency with which a single link-
layer address can be associated with applications to reserve an
address.
This method does not address or support the traceing of ahost using a
known source address. Other mechanisms may be added to enhance the
traceability. For example a log of link layer address of the Seed
Bi, et al. Expires January 28, 2009 [Page 16]
Internet-Draft draft-bi-savi-csa-00 July 2008
Solicitation message could be kept in router. Since link layer
address can also be forged, we have yet to design a totally effective
mechanism.
5.5. Keep-alive
The router MUST send keep-alive message to ensure that the address is
still in use. If the address is not used by any host, the entry in
the mapping table will be cleared. This message can be authenticated
by using the seed already exchanged. Details will be designed in a
future document.
5.6. Other Considerations
Another problem in an access network is that a host can contrive to
receive packets destined for other hosts. There are two situations.
The first of these is the case where bothhosts are in a single
collision domain, and a host can sniff packets sent to the other.
Encrypting the packet to the host is the only way to prevent such
sniffing and our mechanism provides good basics for such encrypting.
Because the worst behaviour of an attacker is sniffing, stopping
sniffing is necessary and sufficient.
The other situation is thatthe hosts are in different collision
domains. An attacker can send spoofed ND message to the router in
order to get packets addressed to another host. Using SEND is a good
choice to prevent such attacks. Attacks in such situation are more
serious because the victim cannot communicate normally and its IP
could be used by others without it being aware.
Bi, et al. Expires January 28, 2009 [Page 17]
Internet-Draft draft-bi-savi-csa-00 July 2008
6. Comparision with Charter
This mechanism is mostly consistent with the charter. Though we only
showed the mechanism satisfied all address allocation method, it can
be used in other situations described in the charter, too. This
document doesn't explain the applicability in all the situations,
since actually it's very obvious.
The gap from this mechanism to the requirement of the charter is
"host change". Although the phase of address authorization can be
regarded as the extension of SEND and the phase of address
authentication can be regarded as the extension of IPSec, the charter
also prohibits "externsions of current protocols". We will discuss
the necessity of "host change" below.
We extend the concept of packet to be all the infomation the
checkpoint gets with the packet, for example, the switch port is also
thought to be the content of the packet.It is obvious that there can
be no perfect filtering mechanism if any two nodes can send the same
packets to the checkpoint. The "perfect filtering" means any packet
can be determined to be valid or not correctly. Though a node can
set the content of the packet above physical layer arbitrarily, it
can not determine the port from which the packet is received by the
switch. Thus the switch port can be used to distinguish packets.
However, if more than one nodes share a port, they have the ability
of spoofing each other's addresses. Only a strict one-one mapping
from port to node can be used to achieve perfect filtering. Actually
switch port and interface of router are the only two elements that
are unspoofable(if other element is found, there will be a new
filtering mechanism). The number of router interface is too rare to
achieve a fine granularity filtering. The switch port is actually
the only information can be used to achieve a fine granularity
filtering. So once there is no strict one-one mapping from port to
node, a host level perfect filtering is impossible.
There is another kind of filtering we call "probability perfect
filtering". In a probability perfect filtering mechanism, a node
still has the ability of generating a "valid" forged packet, but the
probability is very low. A signature-verification mechanism is a
typical probability perfect filtering mechanism. In a probability
perfect filtering mechanism, the sender must have the knowledge of
how to make the space of its valid packets to be very sparse to avoid
spoofing attack, so the sending node must be modified. Though there
is a mechanism that doesn't modify the host end to enable
filtering[hop count filtering], the knowledge used in filtering(the
ttl value) is not secure and the mechanism is very vulnerable.
Therefore, we think the limitation in the charter should be relaxed
Bi, et al. Expires January 28, 2009 [Page 18]
Internet-Draft draft-bi-savi-csa-00 July 2008
to accept other mechanisms not based on filtering at switch port.
Bi, et al. Expires January 28, 2009 [Page 19]
Internet-Draft draft-bi-savi-csa-00 July 2008
7. Acknowledgements
The authors would like to acknowledge the contributors who provided
helpful inputs on earlier versions of this document and Mark Williams
who provided editorial support.
The author gratefully acknowledges the contributions of Fred Baker,
Jari Arkko, Christian Vogt, Xing Li, Pekka Savola, Lixia Zhang, Yan
Shen, Lizhong Xie.
Bi, et al. Expires January 28, 2009 [Page 20]
Internet-Draft draft-bi-savi-csa-00 July 2008
8. References
[CGA] "RFC 3972: Crystographically Generated Addresses(CGA)",
March 2005.
[Privacy] IBM, "RFC 3041: Privacy Extensions for Stateless Address
Autoconfiguration in IPv6", January 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SAC] "RFC 2462: IP Address Autoconfiguration", December 1999.
[SEND] Ericsson, "RFC 3971: SEcure Neighbor Discovery",
March 2005.
[Stateful DHCP]
Cisco, "RFC 3315: Dynamic Host Configuration for IPv6",
2003.
[Stateless DHCP]
Cisco, "RFC 3716: Stateless Dynamic Host Configuration
Protocol(DHCP) service for IPv6", 2004.
Bi, et al. Expires January 28, 2009 [Page 21]
Internet-Draft draft-bi-savi-csa-00 July 2008
Authors' Addresses
Jun Bi
CERNET
Network Research Center, Tsinghua University
Beijing 100084
China
Email: junbi@cernet.edu.cn
Jianping Wu
CERNET
Network Research Center, Tsinghua University
Beijing 100084
China
Email: jianping@cernet.edu.cn
Guang Yao
CERNET
Network Research Center, Tsinghua University
Beijing 100084
China
Email: yaog@netarchlab.tsinghua.edu.cn
Bi, et al. Expires January 28, 2009 [Page 22]
Internet-Draft draft-bi-savi-csa-00 July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Bi, et al. Expires January 28, 2009 [Page 23]