Network Working Group J. Bi Internet-Draft J. Wu Intended status: Experimental L. Xie Expires: December 3, 2007 CERNET June 2007 A Signature based Source Address Validation Method for IPv6 Edge Network draft-bi-sava-solution-ipv6-edge-network-signature-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 December 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Bi, et al. Expires December 3, 2007 [Page 1] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 Abstract Today's Internet is suffering from reflection-type DoS/DDoS attacks, such as TCP SYN flood, Smurf attack, DNS reflection, etc. These attacks often rely on the IP source address spoofing. Current source address spoofing prevention methods have a coarse granularity, and the attackers can still in some cases launch reflection-type DoS/DDos attacks or other attacks while being difficult to trace. Aiming to solve this problem, this document proposes a fine-granularity source address spoofing prevention method, which can prevent the attackers from forging source addresses that belong to the same edge network to send packets to somewhere outside the IPv6 edge network. The proposed method includes source address authentication using session key and hash digest algorithms and replay attack prevention by combining a sequence number method with a timestamp method. Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. The Solution . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. The Source address validation algorithm . . . . . . . . . 11 4.3. The Anti-replay Algorithm . . . . . . . . . . . . . . . . 12 5. IPv6 Source Address Validation Header . . . . . . . . . . . . 14 6. Performance and Effectiveness Evaluation . . . . . . . . . . . 16 7. An Application Case . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Bi, et al. Expires December 3, 2007 [Page 2] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 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 December 3, 2007 [Page 3] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 2. Problem Statement The source address spoofing prevention approaches based on filtering (e.g. ingress filtering) can validate the source address in real- time. Current approaches based on filtering, however, only validate the IP source address according to the network prefix, so these approaches cannot prevent IP source address spoofing within edge network. Thus, they leave some room to launch reflection-type DoS/ DDoS attacks and make traceback uncertain. For instance, if the Internet were to deploy ingress filtering on a large scale, an attacker would be prevented from forging an IP source address belonging to any other edge network, defeating most reflection-type DoS/DDoS attacks. However, even with ingress filtering [RFC2827], the attacker can still forge an IP source address that belongs to the same edge network and attack the victim using the reflection-type DoS/DDoS. This type attack scenario is shown in Fig.1: Bi, et al. Expires December 3, 2007 [Page 4] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 /----------\ /----------\ | Reflector| | Reflector| \--.------./ \-----,----/ /.\ /.\ . --.--/ / | | \ /| /| | / ___ | , _.`'-/'`,'. ' | |,' ``|''--\` / \/ | ,| | \ / /`. | ,..---/ | \ .' / '''''|. ,,- | | \ / / | | _.-'`` | | \ / | | ,' / | ' \ / | | / request: | | ,' \ / | | | src=victim | | / \ / reply: | \ | dst=reflector / | ` \ src=reflector - | | | ,' / \ dst=victim | ` | | |/ / \ | \ | | | / \ | \ , | ,'| / \ | | | | / | / \ | | , | ` | / , | ,- \ | ,' | / \ | ,.-` / | / | ` \ | / | | - | / \| \|/ \ , / ,' | / --' | \ /--\----\ /--\--/-\ /-------\ | \ | Slave | | Slave | | Victim| | `. \---.---/ \--.----/ \-------/ \ / /|\ --, | / | ,'| | ' | - / | | ,' Edge Network ,` \ /--\----`----\ .` ', | Master | ,-` ',\------------/ .` - - . ,-'`-` \ / `' -, | `. / `. | `'., | \ / `', / `''-- `'` Figure 1: Reflection-type DDoS attack in the same edge network This type of security threat may be more serious in IPv6 networks, because the IPv6 edge network may be much larger than in IPv4. In this situation, the ingress filtering may be insufficient and a fine granularity source address spoofing prevention method needs to be developed. For this purpose, this document proposes a suite of Bi, et al. Expires December 3, 2007 [Page 5] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 mechanisms to prevent source address spoofing in the edge network. The edge network this document addresses is the network behind the first 3-layer device (router, 3-layer switch, etc.). The edge network uses the border 3-layer device to communicate with other networks. This document aims to prevent source address spoofing when the host in the edge network sends packets to somewhere outside this edge network. In addition, replay attacks are handled. If only forged IP source addresses can be identified, a replay packet can still be sent to somewhere outside the edge network since its source address is valid. Therefore, identifying packets with forged source addresses anti-replay attack defense are two essential components of an integrated source address spoofing prevention method. Bi, et al. Expires December 3, 2007 [Page 6] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 3. Related Work Current work on security problems in edge networks is concentrated on access control, such as IEEE 802.1x [IEEE-802-1x], NAC [NAC], NAP [NAP] and TNC [TNC]. IEEE 802.1x is a standard for port-based network access control, which provides authenticated network access to 802.11 wireless networks and to wired Ethernet networks. The authentication of 802.1x simply controls the enabling of a switch port and in some cases the allocation of a VLAN. If the user with the legitimate account and password accesses the network, the corresponding switch port will be enabled for transit. If the user does not have the legitimate account and password or there is no user to access the network, the corresponding switch port will stay closed. 802.1x uses EAP (Extensible Authentication Protocol) [RFC3748] to carry out its authentication process. EAP is an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as IEEE 802, without requiring IP. NAC (Network Admission Control) is proposed by Cisco. NAC ensures that the access hosts are compliant with the security policies. Any noncompliant hosts cannot access the network, and they will be isolated until brought into compliance. NAP (Network Access Protection) is another security access mechanism proposed by Microsoft. NAP platform provides a suite of integrity- checking methods to check the 'healthy' state of access hosts. Hosts that do not conform policies defining end-host security stance cannot access the network, and will be placed in quarantine until they are compliant. TNC (Trusted Network Connection) is a framework of trusted network connection supported by about 60 members of TCG (Trusted Computing Group) [TCG]. TNC provides user identity authentication, host trust level validation and network accessibility control on the various trust levels of end systems. These techniques mentioned above are all used to control hosts' access to the network. These techniques range from the simplest, 802.1x, that simply controls access through a switch port to more complex offerings such as NAC, NAP and TNC, that offer more complicated network access controls such as security policy enforcement, etc. All of these techniques only have effect when hosts try to access the network. Once the host accesses the network successfully, the Bi, et al. Expires December 3, 2007 [Page 7] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 subsequent packets sent from this host are typically unauthenticated, and source IP address spoofing becomes possible. Therefore, in the field of edge network security, it is not sufficient simply to ensure that the access process is secure. In order to defeat reflection- type DoS/DDoS attacks mentioned in the problem statement Section, it is necessary to validate every packet originating in the edge network and prevent the source IP address spoofing in the edge network. Bi, et al. Expires December 3, 2007 [Page 8] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 4. The Solution 4.1. Overview This document proposes a fine-granularity source address spoofing prevention method, which can prevent the attackers from forging source address that belongs to the same edge network to send packets to somewhere outside the IPv6 edge network. In this approach, if the attacker sends packets to somewhere outside the edge network by forging the IP address of another host or replays the victim's packets, these malicious packets will be filtered. Moreover, the method can work with other effective but coarser-granularity methods such as ingress filtering or SPM[Bre05] to form a multi-fence defense architecture for the next generation Internet. The main idea is that: we deploy a security gateway to carry out the authentication algorithm as shown in Figure 1. The authentication algorithm includes two main mechanisms: the source address validation mechanism which verifies the source address using a session key a hash digest algorithm (such as MD5, SHA-1, etc.), and the anti-replay mechanism which combines the sequence number method with the timestamp method. Bi, et al. Expires December 3, 2007 [Page 9] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 -, _. `'., ,-` `-, IPv6 Backbone ,-` `'., _.'` `'., _.--., _,-` ``'/ `,` / , | Router | \ ` `. ' ___ _.`'-/'` `. ,' ```''---` | \ ,' | `. ,,..--- +----------\------+ ''''''. / | Secuity Gateway| | | +--------/--------+ | , _. | -, | \ _-` | `'., | \ -` | `- \ `. /------\ | /------\ - / | Host | \ | Host | ` / \------/ /------\ \------/ \ ' | Host | \ | \------/ | \ | ', IPv6 Edge Network ,- ', ,.-` - - . ,-'` \ / `' -, | `. / `. | `'., | \ / `', / `''-- `'` Figure 2: The deployment scenario Initially, each host in the edge network needs to be authenticated by the security gateway. This action also binds the host's IP address and its session key which is shared by the host and the security gateway. If the access authentication succeeds, each packet sent to somewhere outside the edge network will carry a signature. Then, the packet passes through the source address validation and the anti- replay check of the security gateway. If both these verifications succeed, the packet will be forwarded to the edge 3-layer device of the edge network; otherwise, the packet will be dropped. The approach mainly includes the following steps: Bi, et al. Expires December 3, 2007 [Page 10] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 1. When a host wants to access the Internet, it should firstly carry out the access authentication. This process can use the existing access authentication mechanism such as RADIUS [RFC2865]Kerberos [RFC1510], etc. 2. The host generates a session key and sends it to the security gateway via some key exchange mechanisms such as IKE [RFC2409], IKE2 [RFC4306]. The security gateway binds the session key and the host's IP address. 3. When the host sends packets to somewhere outside the edge network, it needs to generate one signature for each packet using the hash digest algorithm. The signature is carried in a new IPv6 extension header, named 'source address validation header'. 4. The security gateway authenticates the signature carried in the packet to validate the source address. 5. The security gateway identifies the replay packets by checking whether the timestamp of the packet is expired and the sequence number of the packet is increasing. In above steps, network access authentication and the key exchange mechanisms can use the existing approaches. Next, this document mainly discusses the source address validation algorithm and the anti-replay algorithm. 4.2. The Source address validation algorithm This document chooses the algorithm which verifies the source address using the session key and hash digest algorithm (such as MD5, SHA-1, etc.) as the authentication method. In this algorithm, the host certifies its ownership of a certain IP address via showing the security gateway its secret session key which is shared with the security gateway as shown inFigure 3. Bi, et al. Expires December 3, 2007 [Page 11] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 +--+ /----\ +--------+ /----\ /-------\ |M |------------>|-|| |------>| M |--->| || |--->| HASH |----/ +/-+ \-.--/ +--------+ \----/ \-------/ | | /|\ | H[M||S]| /|\ | | | +----/---+ | \|/ | /----\ /--\----\ | +------\--------+ /---------\ \-->| || |---->| HASH | | | session key S | | Compare | \-.--/ \-------/ | +---------------+ \---------/ /|\ | . | | /|\ +------\----------+ | | | session key S | \-------------------------------\ +-----------------+ Figure 3: The authentication process of source address validation The authentication process shown in Figure 3 is as follows: 1. Host A sends a packet M to the security gateway B. M carries a signature H[M||S] which is computed by the hash digest function using the session key S and the certain part of the packet M (source address, timestamp, sequence number, etc.) as the input. 2. When the security gateway B receives the packet M, B can re- compute the hash value HB according to the packet M, since B also knows the session key S. If HB is equal to the signature H [M||S] carried in the packet M, the security gateway B can confirm that the packet has a valid source address; Otherwise, B can conclude that the packet's source address is forged and then drops it. 4.3. The Anti-replay Algorithm Our anti-replay algorithm combines the timestamp method and the sequence number method. Both the timestamp method and the sequence number method are prevailing anti-replay algorithms. The timestamp method works as follows: when the host A sends a packet M to the security gateway, the packet M is marked with a timestamp Ta, which represents the sending time of the packet M. Once the security gateway receives the packet M, it reads its local time Tb. If |Tb- Ta|>T, where T is the admission time window, the security gateway can conclude that the packet M is a replay of a previoualy-sent packet and drops it. However, it is hard to synchronize the clocks of the host and the gateway exactly. Moreover, network latency is uncertain. Therefore, the admission time window T is always larger Bi, et al. Expires December 3, 2007 [Page 12] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 than the real transmission time of the packet. This feature could make the timestamp method insecure for anti-replay. When |Tb-Ta| is less than T, the packet should be a non-replay one. But afterwards, if the replay packet is received in the margin time (T-|Tb-Ta|), the security gateway will incorrectly regard it as a normal packet. The main idea behind the sequence number method is: when the host A sends packets to the security gateway, each packet carries an incremental sequence number. If the latest packet's sequence number is greater than the previous one, the packet is normal; otherwise, the packet is a replay. This method requires the packets coming in order. If the packets come out of order, one can employ a sequence number window to deal with it, as with IPSec. Out-of-sequence arrival of packets is mainly due to the load balancing policy or queuing in routers or other 3-layer devices. This document deals with the situation behind the first 3-layer device, thus we can assume that the packets sending to security gateway from hosts in the edge network are always in order. (Or at the very least, out-of- sequence arrival is so rare that the rate of packet discard due to sequence error is low compared to other causes of packet loss) However, even though the packets come in order, this method may not identify some replay packets when the sequence number is used in a cycle way. For example, assuming the length of the sequence number is 16 bits, once the sequence number reaches the maximum 65535, it will return to 0 and increase as the previous cycle. In this case, if the attacker keeps a packet of the nth cycle and replays it in the (n+1) th cycle, the security gateway will not identify the replay packet. In order to overcome the drawbacks of the timestamp and sequence method, we combine these two methods to prevent the replay attack. The timestamp method can use the sequence number mechanism to identify the replay packets in the admission time window T, and the sequence method can avoid the confusion between the normal and the replay packet by limiting the period of the sequence number cycle within the admission time window T. Bi, et al. Expires December 3, 2007 [Page 13] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 5. IPv6 Source Address Validation Header This approach utilizes a new IPv6 extension header to carry the signature, the sequence number and other useful information. We call this new extension header 'source address validation header'. 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 | Payload Len | Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authentication Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: The format of the IPv6 source address validation header The format of the extension header is shown in Figure 4: o Next Header: 8-bit. Indicate either the type of the next extension header or the protocol type of the payload (TCP/UDP). o Payload Len: 8-bit. Length of the source address validation header in 8-octet units, not including the first 8 octets. o Algorithm: 8-bit. Point out the hash digest algorithm. For example, MD5 is set to 1. o Reserved: 8-bit. Reserved for future use. Zero on transmit. o Timestamp: 32-bit. It is used for anti-replay as described above. o Sequence Number: 32-bit. It is used for anti-replay as described above. o Authentication Data: 128 bits if using MD5 as the hash digest algorithm. The authentication data is computed by the hash digest Bi, et al. Expires December 3, 2007 [Page 14] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 algorithm. The input of the hash digest algorithm includes: IPv6 source address, timestamp, sequence number and session key. The usage of IPv6 source address validation header is as follows: 1. Each packet sent to somewhere outside the edge network needs to carry a source address validation header. The header is inserted after the IPv6 header and before all the other extension headers. 2. The security gateway conducts the following verifications when receiving the packet: -Drop the packet directly if there is no source address validation header in the packet. -Check the authentication data in the source address validation header as described above. Drop the packet if the check is failed. -Confirm that the timestamp is not expired and the sequence number is greater than the previous. If that is not true, drop the packet. 3. If the whole process in the step 2 goes well, the security gateway needs to remove the source address validation header from the packet. Considering the partial deployment, if we don't remove the source address validation header, the hosts in other edge network may drop the packet due to misunderstanding of the new extension header. This step is unnecessary if our approach has been globally deployed. Bi, et al. Expires December 3, 2007 [Page 15] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 6. Performance and Effectiveness Evaluation The performance is a primary requirement of any source address validation mechanism. In our approach, this requirement reduces to the question of whether the performance of the hash digest algorithm is sufficient. Experimental result show that the performance of MD5 is about 1.63 Gbps (204.346MB/s * 8),which is evaluated in the platform of Intel P4 2.0G CPU and 512M memory. This performance can meet the requirements of most edge networks. We should note that this result is derived from the MD5 algorithm being implemented in the software. If we implement the MD5 algorithm using hardware, we will get higher performance. We conclude therefore, that the source address validation algorithm in our approach is completely feasible. In order to testify the effectiveness of our anti-replay algorithm which integrates timestamp and sequence number methods, we conducted several experiments to compare the effects of the timestamp, sequence number and our anti-replay algorithm. The experiments show that the effectiveness of timestamp method seriously relies on the size of admission time window T. As the margin of the admission time window T is increased, the effectiveness of the timestamp method decreases. In the experiment to test effectiveness of the sequence number method, the accuracy of replay packets identification in the (n+1)th sequence number increasing cycle is linear with the packet number recorded in the nth sequence number increasing cycle. The experimental result shows that almost all packets recorded can be replayed successfully under conditions of persistent replay. We repeated the above two simulation experiments to test the effectiveness of our anti-replay algorithm which integrates the timestamp and the sequence number methods. Even though the admission time window T has a large margin, with the help of sequence number method, all replay packets are identified successfully. In the (n+1)th sequence number increasing cycle, when attacker replays the packets recorded in the nth sequence number increasing cycle, the security gateway can identify nearly 100% replay packets since the intervals between replay packets and normal packets exceed the admission time window T. Our experiments show that the source address validation algorithm this document proposed prevent the attackers from forging source address that belongs to the same edge network to send packets to somewhere outside the IPv6 edge network effectively. The anti-replay algorithm this document proposed can overcome the shortcomings of both timestamp and sequence number methods, and form a more effective, fine-grain anti-replay mechanism. Bi, et al. Expires December 3, 2007 [Page 16] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 7. An Application Case Multihoming to upstream ISPs is increasingly common in the Internet. Multihoming refers to the phenomenon that one edge network accesses to the Internet through multiple upstream ISPs. In the multihoming environment, a host in the edge network may have several ISP-assigned IP addresses and the edge network may have several outbound links to different ISPs, which makes the source address spoofing prevention complicated. This document proposes a solution for the multihoming scenario as shown in Figure 5. In our solution, each edge router of the edge network is equipped with a security gateway. Each security gateway is responsible for handling the addresses assigned from the ISP to which that security gateway is attached. For example, in Figure 5, the security gateway A just handles the addresses assigned from ISP A. Other than this, the security gateway performs the same functions as the single-homed situation described above. Another problem is that the security gateway may be confused in the multihoming situation since outbound packets are routed by the destination address. For example, in Figure 5, when host A sends packets using the addresses based on prefix A (PrefixA:PrefSite: hostA) as the source addresses, the packets could be sent to the edge router B connected to ISP B, and the security gateway B will be confused and take the wrong action. In order to solve this problem, packets originating in the edge network are passed through a source routing domain (shown in Figure 5) to which all edge routers are connected. These routers would choose a route based on the destination and source addresses of a packet, selecting the appropriate edge router for the given source address. In this way, our source address spoofing prevention method can work well in the multihoming scenario. Bi, et al. Expires December 3, 2007 [Page 17] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 .```, .```, ,.-----` . ,.-----` . / ISPA '-, / ISPA '-, | \ | \ . ,--., | . ,--., | _/ ,' \ / _/ ,' \ / \ | | / / \ | | / / `'-| Router -, ` `'-| Router -, ` \'''''./ \'''''./ `'-/'` `'/-' | | | | | | | \ \ +-------\---------+ +------\----------+ | Secuity Gateway| | Secuity Gateway| +--------/--------+ +--------/--------+ | | ,\-., ,-\., PrefixA::/n ,' \ ___ _.`'-/'` `. ,' \ PrefixB::/n | ,| ```''---` \ | | | Router | `| Router | ,,\.--- / \'''''./ / `'--/` `'.-'`| | | | | , -----------------/---------------\ | \ | | \ | \ `. /--\---\ - / | HostA| ` / \------/ \ ' PrefixA:PrefixSite:HostA \ | PrefixB:PrefixSite:HostA | \ | ', ,- ', IPv6 Multihomed Network ,.-` - - . ,-'` \ / `' -, | `. / `. | `'., | \ / `', / `''-- `'` Figure 5: A application case for the multihomed site Bi, et al. Expires December 3, 2007 [Page 18] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 8. 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. Bi, et al. Expires December 3, 2007 [Page 19] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 9. References [Bre05] Bremler-Barr, A. and H. Levy, "Spoofing Prevention Method", Infocom 2005, 2005. [IEEE-802-1x] "IEEE Standard for Local and metropolitan area networks: Port-Based Network Access Control", 2001. [NAC] "NAC", http://www.cisco.com/en/US/netsol/ns617/ networking_solutions_sub_solution_home.html . [NAP] "NAP", http://www.microsoft.com/technet/network/nap/ default.mspx . [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [TCG] "TCG", https://www.trustedcomputinggroup.org/home . [TNC] "TCG Trusted Network Connect TNC Architecture for Interoperability", 2005. Bi, et al. Expires December 3, 2007 [Page 20] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 Authors' Addresses Jun Bi CERNET Network Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Jianping Wu CERNET Network Center, Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Lizhong Xie CERNET Network Center, Tsinghua University Beijing 100084 China Email: xlz@netarchlab.tsinghua.edu.cn Bi, et al. Expires December 3, 2007 [Page 21] Internet-Draft SAVA Solution for IPV6 Edge Network June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bi, et al. Expires December 3, 2007 [Page 22]