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]