Network Working Group J. Wu Internet-Draft J. Bi Intended status: Experimental X. Li Expires: August 11, 2007 M. Ye CERNET February 7, 2007 A End-to-end Source Address Validation Solution for IPv6 draft-wu-sava-solution-e2e-ipv6-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 August 11, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Wu, et al. Expires August 11, 2007 [Page 1] Internet-Draft E2E SAVA Solution for IPV6 February 2007 Abstract This document describes the detail mechanism and protocol definition of a light-weight signature based and end-to-end deployed method for preventing the spoofing of source IPv6 address. Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview of the Solution . . . . . . . . . . . . . . . . . . . 7 4.1. Basic Mechanism . . . . . . . . . . . . . . . . . . . . . 7 4.2. System Architecture . . . . . . . . . . . . . . . . . . . 7 4.3. Advantages . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3.1. Deploymnent Incentive . . . . . . . . . . . . . . . . 9 4.3.2. Incremental Deployment . . . . . . . . . . . . . . . . 9 5. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Modification to the Routers . . . . . . . . . . . . . . . 11 5.3. Presentation of Prefix Ownership . . . . . . . . . . . . . 12 5.4. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Packet Processing Steps . . . . . . . . . . . . . . . . . 13 5.5.1. Processing Steps for Incoming Packets . . . . . . . . 14 5.5.2. Processing Steps for Out-going Packets . . . . . . . . 14 6. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 16 6.3. Control Data in Registration Server . . . . . . . . . . . 16 6.4. Control Data in AS Control Server . . . . . . . . . . . . 16 6.4.1. E2E Alliance Member List . . . . . . . . . . . . . . . 17 6.4.2. Local Prefix List . . . . . . . . . . . . . . . . . . 17 6.4.3. Prefix-AS Mapping Table . . . . . . . . . . . . . . . 17 6.4.4. AS-In Signature Table . . . . . . . . . . . . . . . . 18 6.4.5. AS-Out Signature Table . . . . . . . . . . . . . . . . 18 7. Protocol Between Registration Server and AS Control Server . . 19 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 19 7.2.1. INFO_REQUEST Message Formats . . . . . . . . . . . . . 19 7.2.2. INFO_REQ_ACK Message Formats . . . . . . . . . . . . . 20 7.2.3. INFO_REQ_NAK Message Formats . . . . . . . . . . . . . 21 Wu, et al. Expires August 11, 2007 [Page 2] Internet-Draft E2E SAVA Solution for IPV6 February 2007 7.2.4. INFO_NOTIF Message Formats . . . . . . . . . . . . . . 21 7.3. Possible Scenarios . . . . . . . . . . . . . . . . . . . . 22 7.3.1. PASC Initiate Request to the REG . . . . . . . . . . . 22 7.3.2. REG Initiate Notification to the ASC . . . . . . . . . 23 8. Protocol Between AS Control Servers . . . . . . . . . . . . . 24 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 24 8.2.1. PREFIX_REQEUST Message Formats . . . . . . . . . . . . 24 8.2.2. PREFIX_REQ_ACK Message Formats . . . . . . . . . . . . 25 8.2.3. PREFIX_REQ_NAK Message Formats . . . . . . . . . . . . 26 8.2.4. PREFIX_NOTIF Message Formats . . . . . . . . . . . . . 27 8.2.5. SIG_OUT_NOTIF Message Formats . . . . . . . . . . . . 27 8.2.6. SIG_OUT_OK Message Formats . . . . . . . . . . . . . . 28 8.2.7. SIG_KEEPALIVE Message Formats . . . . . . . . . . . . 29 8.3. Procedure for Prefix Information Exchange . . . . . . . . 29 8.3.1. ASC Initiate Request to Another ASC . . . . . . . . . 29 8.3.2. ASC Initiate Notification to other ASCs . . . . . . . 30 8.4. Procedure for Signature Information Exchange . . . . . . . 31 8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 31 8.4.2. Procedure of Managing the Signature . . . . . . . . . 32 8.4.2.1. Start to Use the Signature . . . . . . . . . . . . 32 8.4.2.2. Periodically Change the Signature . . . . . . . . 33 8.4.2.3. Handle Out of Synchronization of the Signature . . 33 8.4.3. FSM for the Incoming Direction Signature . . . . . . . 34 9. Other Discussion . . . . . . . . . . . . . . . . . . . . . . . 37 9.1. Coexist with IPSEC . . . . . . . . . . . . . . . . . . . . 37 9.2. Difference from IPSEC . . . . . . . . . . . . . . . . . . 37 9.3. The Overhead of Communication Between AS Members . . . . . 37 9.4. Method For Guessing the Signature . . . . . . . . . . . . 37 10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 39 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 12. Security Considerations . . . . . . . . . . . . . . . . . . . 41 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 45 Wu, et al. Expires August 11, 2007 [Page 3] Internet-Draft E2E SAVA Solution for IPV6 February 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]. Wu, et al. Expires August 11, 2007 [Page 4] Internet-Draft E2E SAVA Solution for IPV6 February 2007 2. Introduction The Internet is a decentralized system which basically provides best effort, packet-based data forwarding service. In the forwarding process, the device (router, switch, gateway, etc.) forwards IP packets based on the destination IP address. In most cases, the source IP address is not checked. The lack of source IP address checking makes it easy for the attackers to spoof the source address. And it has facilitated many existing attacks in the Internet. Some mechanisms, such as Ingress Filtering [RFC2827], iTrace [I-D.bellovin-itrace], SAVE [Li02], etc., has been proposed to solve the problem of source IP address spoofing. However, these mechanisms are not widely deployed in the Internet. There are two main reasons that impede the deployment: the lack of enough incentive for deployment, and the lack of capability for incremental deployment. In [Bre05] Bremler-Barr and Levy proposed a idea to prevent source address spoofing. A unique temporary key is shared between two ASes. When a pakcet is leaving a source network, it is tagged with the key. When this packet arrives at the destination network, the key is verified and removed. This mechanism shows its benefits both at providing incentive for deployment and at ease of incremental deployment. However, the detail mechanism is not designed and some issues were not discussed, e.g, MTU issue, the presentation of address prefix ownership, etc. This document makes detail specification for a light-weight signature based end-to-end deployed source address validation solution for IPv6. In addition to this document, we also finished the prototype implementation, and verified the mechanism in CERNET2 native IPv6 environment (7 core nodes and 10 ASes had been deployed). Currently we only consider how to apply the mechanism in the IPv6 network, because the deployment is more fesible for the next generation Internet. For applying it in the IPv4 network, the mechanism is quite similar. The section 4 provides an overview of the solution. The section 5 describes the mechanisms at data plane. The section 6 provides an overview for the control plane. The section 7 describes protocol between registration server and AS control server. The section 8 describes protocol between two AS control servers. Wu, et al. Expires August 11, 2007 [Page 5] Internet-Draft E2E SAVA Solution for IPV6 February 2007 3. Terminology E2E Alliance: A group of ASes that apply E2E mechanism to prevent source address spoofing. Registration Server(REG): A server that maintains the E2E Alliance member list. AS Control Server(ASC): A server that represents one AS member to communicate with Registration Server and other AS members in E2E Alliance. AS Edge Router(AER):A router deployed at the edge of AS that processes packets with E2E mechanism. Signature: The 48-bit string carried on each data packet when the packet is tranmitted between two AS members in the E2E Alliance. E2E Option: Option in IPv6 Hop-by-Hops Options header that carries 48-bit signature required by E2E mechanism. E2E Header: A type of IPv6 extension header that carries 48-bit signature required by E2E mechanism. Wu, et al. Expires August 11, 2007 [Page 6] Internet-Draft E2E SAVA Solution for IPV6 February 2007 4. Overview of the Solution 4.1. Basic Mechanism The basic ideas of E2E mechanism are as follows: o All ASes that applying E2E mechanism form an E2E Alliance. o Each AS in the E2E Alliance guarantees the validity of the source IP address of the packet generated by this AS. o When a packet is leaving its own original AS, if the destination IP address belongs to some AS member in the E2E Alliance, the edge routers of this AS looks up for the signature based on the destination AS number, and tags a signature to the packet. o When a packet is arriving at the destination AS, if the source address of the packet belongs to some AS member in the E2E Alliance, the edge routers of the destination AS looks up for the signature based on the source AS number. then the signature carried in the packet is verified and removed. There are several very important assumptions for the feasibility of E2E mechanism: o It is hard for an attacker to sniff the backbone between AS in the Alliance. o Even some transit ASes don't join the E2E Alliance, they will not try to be harmful to the E2E Alliance. Under these assumptions, we can use shared random number as the signature, instead of using cryptographic method to generate the signature. 4.2. System Architecture Here we briefly describe the system architecture, as shown in Figure 1. Wu, et al. Expires August 11, 2007 [Page 7] Internet-Draft E2E SAVA Solution for IPV6 February 2007 +-----+ | REG | +-----+ ,-------------- ,-------------- ,' ` `. ,' ` `. / \ / \ / \ / \ ; +-----+ +----+ +----+ +-----+ ; | | ASC | |AER | |AER | | ASC | | : +-----+ +----+` +----+ +-----+ : \ / \ / \ / \ / `. ,' `. ,' '-------------' '-------------' AS-1 AS-2 Figure 1. Architecture There are three major components in the system: the Registration Server(REG), the AS Control Server(ASC), and the AS Edge Router(AER). The Registration Server is the "center" of the E2E Alliance. It maintains a member list for E2E Alliance. It can support two major functions: o Process the request from the AS Control Server, to get the member list of the E2E Alliance. o When the member list is changed, notifiy each AS Control Server. Each AS deploying the method should have an AS Control Server. The AS Control Server has three major functions: o Communicate with the Registration Server, to get the up-to-date member list of E2E Alliance. o Communicate with the AS Control Server in other member AS in E2E Alliance, to exchange the update in prefix ownership, and to exchange the signature. o Communicate with all edge routers of the local AS, to configure the processing component on the edge routers. The AS Edge Router does the work of adding signature to the packet at the sending AS, and the work of verifying and removing the signature at the destination AS. Wu, et al. Expires August 11, 2007 [Page 8] Internet-Draft E2E SAVA Solution for IPV6 February 2007 In the design of this system, we try to decrease the burden of Registration Server. Most of the control traffic happens between AS Control Servers. 4.3. Advantages 4.3.1. Deploymnent Incentive The E2E mechanism presented in this document provides strong incentive for the network operator to deploy it; second, it can be incrementally deployed. The incentive provided by the mechanism shows at three apects: o The members in the E2E Alliance may apply some different service mechanism for the traffic from E2E Alliance members and non-members. Traffic from other E2E Alliance members can get better service. o When some abnormal traffic is coming from some other E2E Alliance member, it is easier to trace back the origination. o If the attacking traffic targeting one E2E Alliance member by spoofing the source IP address of another E2E Alliance member, the AS owning the spoofed address can easily prove its innocence. This can help to decrease the overhead of network management. 4.3.2. Incremental Deployment E2E mechanism can be incrementally deployed in the Internet, the main reason is that it is an end-to-end solution. It does not rely on the modification to the middle path routers. E2E mechanism also has some other advantages. It does not rely on route information or path information. So it is not influenced by the dynamics of route changes and route flaps. And it is feasible in the multihoming environment. Wu, et al. Expires August 11, 2007 [Page 9] Internet-Draft E2E SAVA Solution for IPV6 February 2007 5. Data Plane 5.1. Packet Format We must find some space in the IP packet to carry the signature. The packet header of IPv6 packet is quite simplified. It is hard to find space available. One possible way is to make use of the 8-bit Traffic Class area and the 20-bit Flow Label area [RFC2460]. But since it still can not hold the signature with 28 bits, and this usage may break some other protocols that use these two area, we decide not to carry the signature in the IPv6 Header. Instead, we design a new E2E Option in Hop-by-Hop Options header [RFC2460] to carry the signature. The signature carried in the E2E Option is 48-bit long. In [Bre05], the authors described a scenario how two hosts can colloborate to guess the signature, and the original design for the signature is 32- bit long. However, in case of thousands of machines are controlled to cooperatively guess the signature, 32-bit signature is vulnerable. So the signature is extended to 48-bit long. The E2E Option has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1|x x x x x|0 0 0 0 0 1 1 0| Signature (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first two bits of the first byte are zero. If the processing IPv6 node does not recognize E2E Option, it just skips over this option. The third bit is 1, since the option data may change en- route. The next five bits is the Hop-by-Hop Option Type number, are left to be specified. The second bit indicates the length of the option data. The length of E2E Option data is 6-byte. Next is the 48-bit signature data. There MUST only be one option of this type, regardless of value, per Hop-by-Hop header. Another possible way to carry signatur is to insert an extension header. The E2E Header has the following formats: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Signature (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wu, et al. Expires August 11, 2007 [Page 10] Internet-Draft E2E SAVA Solution for IPV6 February 2007 If signature is carried in the Hop-by-Hop Options header, to keep the 8-octet alignment required by RFC2460 [RFC2460], some extra bytes should be inserted for padding. Also considering the possibility that there may be Hop-by-Hop Options header already in the packet, the processing at the edge router is relative complex. On this aspect, carrying signature in the extension header is relatively simpler. The advantage of using Hop-by-Hop Options header is that it will not cause ICMP packet with value "unrecognized Next Header type encountered". Routers that don't know E2E Option can just skip this option. While packet with the extension header may cause ICMP packet with value "unrecognized Next Header type encountered", depending on the specific router implementation. 5.2. Modification to the Routers The AS edge routers should support the following three functions: o Drop those coming packets whose source address belongs to the local AS. Such packets may be generated from spoofing of source address, or from loop of route. In both cases, the packets should be dropped. o Tag signature to the out-going packets whose destination address belongs to another AS in the E2E Alliance. o Verify and remove the signature of the incoming packet. A packet with signature SHOULD NOT reach inside the AS. To support these functions, some components should be added to the edge routers: o Local prefix list table. It stores all prefix owned by the local AS. It is used in processing the incoming packet, to check the source address in the packet. o Prefix-AS mapping table. It maps prefix to the AS which owns the prefix. It is used both in processing the incoming packet and in processing the out-going packet. o AS-In signature table. It stores the signature for the incoming traffic. o AS-Out signature table. It stores the signature for the out-going traffic. Wu, et al. Expires August 11, 2007 [Page 11] Internet-Draft E2E SAVA Solution for IPV6 February 2007 5.3. Presentation of Prefix Ownership Each AS should present the ownership of prefix. Since Longest Prefix Match is applied in the current forwarding lookup method, in the presentation of the prefix ownership we should also notice this property. In a prefix table table, there is not only the prefix block that owned by this AS, but also some small prefix block that not owned by this AS. Thus the prefix table entry is organized as: o Prefix: prefix address. o Prefix length: length of the prefix. o Flag: whether the prefix is owned by this AS. If the prefix is owned by the AS, the flag is YES; if the prefix is not owned by the AS, the flag is NO. In checking the prefix table to get the ownership of the prefix, there are three cases: o No matched prefix: the prefix is not owned by the AS. o The prefix is matched, the flag is YES: the prefix is owned by the AS. o The prefix is matched, the flag is NO: the prefix is not owned by the AS. 5.4. MTU Issues Since E2E Option in Hop-by-Hop Options head is inserted into the out- going packet, MTU issues should be considered. The length of E2E Option is 8-byte. If there is no Hop-by-Hop Options header in the original packet, 16 bytes will be added to the packet. If there has been Hop-by-Hop Options head in the original packet, 8 to 16 bytes will be added to the packet. For simplifying the problem, we always assume that 16 bytes will be added to the packet. The problem is depicted in Figure 2. Host A in the AS-1 sends packet to Host B. The MTU for the output link of the edge router is x. The AER sends an ICMP "Packet Too Big" [RFC2463] message to Host A, and Host A changes its MTU to x-16, i.e., minus length of E2E Option. There is a gateway between Host A and Host B, and MTU of one link is y (y < x). The gateway will send an ICMP "Packet Too Big" message to Wu, et al. Expires August 11, 2007 [Page 12] Internet-Draft E2E SAVA Solution for IPV6 February 2007 Host A, and Host A will change its MTU to Host B to y. However, after forwared by the AER, the packet size becomes y+16, and it still can not accepted by the gateway. ,-------------- ,' ` `. / \ / mtu = x-16 \ mtu = x mtu = y < x ; +---+ +----+ +----+ +---+ | | A |--------|AER |----------| GW |--------| B | : +---+ +----+` +----+ +---+ \ mtu = y / y + 16 y + 16 > y \ / `. ,' '-------------' AS-1 Figure 2. MTU issue Someone may ask why there is such problem, if comparing with some tunnel mechanism. The reason is that AER router inserts E2E option but doesn't change the source address of the packet. Thus the down- stream gateway sends ICMP "Packet Too Big" to the host, not to the AER. Currently we have two solutions to this problem. Both of the solutions are not so perfect, but they are feasible. One possible way is to set the MTU at the AER to be 1280, which is the minimum MTU for the IPv6. Thus there should be no ICMP "Packet Too Big" message received from the down-stream gateways. The disadvantage of this solution is that it doesn't make good use of the available MTU. Also, if the MTU at the AER is 1280, MTU at the host will be 1264. We doubt whether host will accpet such a MTU, since it is smaller than the IPv6 minimum MTU. The other possible way is to let AER catch all coming ICMP "Packet Too Big" message", and decrease the value in the MTU area by 16 before forwarding it into the AS. The advantage of this solution is that it can make good use of the available MTU. But such processing of ICMP packet at AER may become a destination of DoS attack. 5.5. Packet Processing Steps Wu, et al. Expires August 11, 2007 [Page 13] Internet-Draft E2E SAVA Solution for IPV6 February 2007 5.5.1. Processing Steps for Incoming Packets For a packet coming into the AS, the edge router will process it in the following steps: 1. Check the destination address with the local prefix list table. If the destination address matches with the prefix of the local AS, go to the next step; else, just forward it. 2. Check the source address with the local prefix list table. If the source address matches with the prefix of the local AS, drop the packet. 3. Check the source address with the prefix-AS mapping table. If the source address belongs to some AS member in the E2E Alliance, go to the next step; else, forward it. Before forwarding the packet, the packet should be checked to see whether it has E2E option. It is possible to have some cases that the sending AS has changed its prefix list but this information has not reached the local AS. If the packet has E2E Option, the edge router should remove the E2E Option before forwarding this packet into the local AS. 4. Verifty the signature in the packet with the record in the AS-In signature table. If the signature in the packet is invalid, drop the packet; else forward it. In the implementation, some method can be applied to simiplify the processing steps: o The first step could be combined to the normal forwarding lookup for a packet. The local prefix can be added to the forwarding information table (FIB), with some special flags. o The second step and the third step can be combined to one step. The prefix of local AS can be treated as a special case in the prefix-AS mapping table. 5.5.2. Processing Steps for Out-going Packets For a packet going out of the AS, the edge router will process it in the following steps: 1. Check the source address of the packet with the local prefix list table. If the source address matches with the prefix of the local AS, go to next step; else, forward it. 2. Check the destination address with the prefix-AS mapping table. If the destination address belongs to some AS member in the Alliance, Wu, et al. Expires August 11, 2007 [Page 14] Internet-Draft E2E SAVA Solution for IPV6 February 2007 go to next step; else, forward it. 3. Get the signature from the AS-Out signature table with the destination AS number. Insert the E2E Option into the packet and forward it. In the implementation, the first step and the second step can be combined to simiplify the processing steps. The prefix of local AS can be treated as a special case in the prefix-AS mapping table. Wu, et al. Expires August 11, 2007 [Page 15] Internet-Draft E2E SAVA Solution for IPV6 February 2007 6. Control Plane 6.1. Overview In the control plane, the major issues are "two systems" and "two protocols". The "two systems" are the Registration Server and the AS Control Server. The "two protocols" are the protocol between Registration Server and AS Control Server, and the protocol between two AS Control Servers. 6.2. Security Issues How to security the communication between the servers is a very important issue. To avoid the usage of PKI, we decide to use TCP as the tranmission protocol. TCP provides some means of security, it is hard to set up the communication with these servers with spoofed source address. Since we've made the assumption that the link between the ASes is hard to sniff, we don't worry about the control data communication to be sniffed. One possible attack is to try to "insert" fake data into the data stream between two servers, by guessing the Seq and Ack of TCP packet. But since normally the communication between these servers is short flows, it is hard to make such attack. 6.3. Control Data in Registration Server In the Registration Server, a list for all the members in the Alliance is maintained. A list entry has following information for the member: o AS number: 16 bit o Address of AS Control Server: 128 bit, for IPv6 address. o Last action: last operation on this AS member, 8 bit. The operation may be Add or Delete. o Action ID: each action on the member list should have a unique ID number. This nubmer should increase by one for each new action. The operation on the list may be "add a member" or "delete a member". The IP address of the AS Control Server is negotiated by other means. 6.4. Control Data in AS Control Server In the AS Control Server, there are five data tables as follows: Wu, et al. Expires August 11, 2007 [Page 16] Internet-Draft E2E SAVA Solution for IPV6 February 2007 o The E2E Alliance member list: list for member of E2E Alliance. o The local prefix list: prefix owned by the local AS. o The prefix-AS mapping table: map from prefix to the AS number. o The AS-In signature table: map from AS number to the incoming direction signature. o The AS-Out signature table: map from AS number to the out-going direction signature. 6.4.1. E2E Alliance Member List This information of E2E Alliance list is updated from the registration server. Different from the list on the Registration Server, only AS number and the address of AS Control Server are required for each member entry. For the whole list, one "last action ID" value is maintained. This value is the ID of latest action learned from the Registration Server. 6.4.2. Local Prefix List The lcoal prefix list maintains a list for the prefix owned by the local AS. The presentation of prefix ownership has been discussed in Section 5.3.For each entry in the prefix list, the information for a prefix includes prefix, prefix length, and flag, just as described in Section 5.3. There are two additional data areas used to help manage the prefix list: o Last action: last operation on this AS member, 8 bit. The operation may be Add or Delete. o Action ID: each action on the local prefix list should have a unique ID number. This nubmer should increase by one for each new action. 6.4.3. Prefix-AS Mapping Table The prefix-AS mapping table maintains the prefix ownership information of all other AS members in the E2E Alliance. For ease of managing the table, the table should support both mapping from prefix to AS number and mapping from AS number to all owned prefix. The details on operation of prefix-AS mapping table will be discussed in Section 8. Wu, et al. Expires August 11, 2007 [Page 17] Internet-Draft E2E SAVA Solution for IPV6 February 2007 6.4.4. AS-In Signature Table The AS-In table stores the incoming direction signatures with each peer AS members in the E2E Alliance. The details on operation of AS-In signature table will be discussed in Section 8. 6.4.5. AS-Out Signature Table The AS-In table stores the out-going direction signatures with each peer AS members in the E2E Alliance. The details on operation of AS- Out signature table will be discussed in Section 8. Wu, et al. Expires August 11, 2007 [Page 18] Internet-Draft E2E SAVA Solution for IPV6 February 2007 7. Protocol Between Registration Server and AS Control Server 7.1. Overview The function of the protocol between Registration Server and AS Control Server is to spread the information of E2E Alliance list to all AS member in the E2E Alliance. We design two mechanisms to achieve the goal. First, the AS Control Server may initiate a request to the Registration Server to get the list information. Second, when some change happens at the Registration Server, it should notify all AS Control Servers. The communicate is based on TCP connections. 7.2. Message Formats This section describes message formats used in the protocol between Registration Server and AS Control Server. There are four types of messages: INFO_REQUEST, INFO_REQ_ACK, INFO_REQ_NAK, INFO_NOTIF. 7.2.1. INFO_REQUEST Message Formats After a transport protocol connection is established between Registration Server(REG) and AS Control Server(ASC), ASC sends INFO_REQUEST message to the REG. The INFO_REQUEST message contains the follow fields: 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 +-+-+-+-+-+-+-+-+ | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action ID Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Command: This 1-octet unsigned integer indicates the type code of the message. For INFO_REQUEST message, the command value is 1. My Autonomous System: This 2-octet unsigned integer indicates the Autonomous System number of the sender. Action ID Parameter: This 4-octet unsigned integer indicates the action ID parameter for this request. It's the latest action ID that ASC getting from the REG. If the ASC wants to get the information of all the E2E Alliance member, the value should be set to 0. Wu, et al. Expires August 11, 2007 [Page 19] Internet-Draft E2E SAVA Solution for IPV6 February 2007 7.2.2. INFO_REQ_ACK Message Formats After REG receives INFO_REQUEST message from ASC, if the request is valid, the REG will send back INFO_REQ_ACK message to the ASC. The INFO_REQ_ACK message contains the following fields: 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 +-+-+-+-+-+-+-+-+ | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Data Records | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Action ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Records (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Command: This 1-octet unsigned integer indicates the type code of the message. For INFO_REQ_ACK message, the command value is 2. Number of Data Records: This 4-octet unsigned integer indicates the number of the total records returned. Last Action ID: This 4-octet unsigned integer indicates the latest action ID of the records returned. Data Records: This is a variable length field that contains a list of the Alliance member information. Each AS member info record contains the following field: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Autonomous System Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Address (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Action | +-+-+-+-+-+-+-+-+ Autonomous System Number: This 2-octet unsigned integer indicates the Autonomous System number of the member. Server Address: This 16-octet data indicates the IPv6 address of the AS Control Server for this AS member. Wu, et al. Expires August 11, 2007 [Page 20] Internet-Draft E2E SAVA Solution for IPV6 February 2007 Last Action: This is 1-octet unsigned integer indicates the last action for this AS member. The value of this field may be: o Add(1): last action is "add" for this AS member. o Delete(0): last action is "delete" for this AS member. 7.2.3. INFO_REQ_NAK Message Formats After REG receives INFO_REQUEST message from ASC, if the request is invalid, the REG will send back INFO_REQ_NAK message to the ASC. The INFO_REQ_NAK message contains the following fields: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Command: This 1-octet unsigned integer indicates the type code of the message. For INFO_REQ_NAK message, the command value is 3. Error Code: This 1-octet unsigned integer indicates the error type in processing this request. The value of the error code may be: o 1: invalid AS number. The AS that sends the request to the REG has not joined the E2E Alliance. o 2: invalid ASC address. The address of the sending host does not match the address in the E2E Alliance member list. 7.2.4. INFO_NOTIF Message Formats If there are some update to the E2E Alliance member list at the REG, REG should send INFO_NOTIF message to ASC of all the AS member in the E2E Alliance. The INFO_NOTIF message contains the following fields: 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 +-+-+-+-+-+-+-+-+ | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latest Action ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wu, et al. Expires August 11, 2007 [Page 21] Internet-Draft E2E SAVA Solution for IPV6 February 2007 Command: This 1-octet unsigned integer indicates the type code of the message. For INFO_NOTIF message, the command value is 4. Latest Action ID: This 4-octet unsigned integer indicates the action ID of lastest update to the E2E Alliance member list at the REG. 7.3. Possible Scenarios 7.3.1. PASC Initiate Request to the REG ASC may initiate sending request to the REG to get the E2E Alliance list information. For the ASC, the procedure is as follows: 1. ASC connects to the REG. 2. ASC sends INFO_REQUEST message to the REG. If ASC only wants to get the update information, the Action ID Parameter in the message may be the Last Action ID got from the last INFO_REQ_ACK message received from the REG; if ASC wants to get the whole Alliance member list, the Action ID Parameter should set to be zero. 3. ASC receives INFO_REQ_ACK message or INFO_REQ_NAK message from REG. 4. ASC closes the connection. For the REG, the procedure is as follows: 1. REG accepts the connection request from ASC. 2. REG receives INFO_REQUEST message from the ASC. 3. REG validates the AS number in the INFO_REQUEST message. If the AS number is not in the E2E Alliance member list, REG sends INFO_REQ_NAK message with error code set to be "invalid AS number", and REG closes the connection; else, go to the next step. 4. REG validates the peer address of connection. If the address does not match with the record in the E2E Alliance member list, REG sends INFO_REQ_NAK message with error code set to be "invalid ASC address", and REG closes the connection; else, go to the next step. 5. REG sends INFO_REQ_ACK message to ASC, with the requested Alliance member list information. 6. REG closes the connection. Wu, et al. Expires August 11, 2007 [Page 22] Internet-Draft E2E SAVA Solution for IPV6 February 2007 7.3.2. REG Initiate Notification to the ASC When some changes are made to the E2E Alliance member list at the REG, REG should send notification to the ASC of all the member in the E2E Alliance member list. For the REG, the procedure is as follows: 1. REG connects to the ASC. 2. REG sends INFO_NOTIF message to the ASC. 3. REG closes the connection. For the ASC, the procedure is as follows: 1. ASC accepts connection request from REG. 2. ASC validates peer address of the connection. If the address does not match with the recorded REG address (got with other means), ASC closes the connection; else, go to next step. 3. ASC receives INFO_NOTIF message from REG. 4. ASC closes the connection. 5. ASC compares the Latest Action ID in INFO_NOTIF message with the Last Action ID got from last INFO_REQ_ACK message. received. If the action ID in INFO_NOTIF message is more recent, ASC sends request to REG as described in Section 7.3.1; else, ASC makes no action. Wu, et al. Expires August 11, 2007 [Page 23] Internet-Draft E2E SAVA Solution for IPV6 February 2007 8. Protocol Between AS Control Servers 8.1. Overview The protocol between AS Control Servers has two major functions: o Spread the information of local prefix list on each ASC to all other AS members. o Synchronize the signature between each pair of AS members. 8.2. Message Formats This section describes message formats used in the protocol between AS Control Servers. There are eight types of messages. Four types of messages are used in exchanging information on prefix list: PREFIX_REQUEST, PREFIX_REQ_ACK, PREFIX_REQ_NAK, PREFIX_NOTIF. Two types of messages are used in exchanging information on signature: SIG_OUT_NOTIF, SIG_OUT_OK. One type of messages are used in keep- alive function: SIG_KEEPALIVE. 8.2.1. PREFIX_REQEUST Message Formats When ASC wants to get the list of prefix owned by other AS, it connects to the ASC of the AS member. After the connection is established between two ASCs, the requesting ASC sends PREFIX_REQEUST message to other ASC. The PREFIX_REQEUST message contains the follow fields: 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 +-+-+-+-+-+-+-+-+ | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | Peer Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action ID Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Command: This 1-octet unsigned integer indicates the type code of the message. For PREFIX_REQEUST message, the command value is 5. My Autonomous System: This 2-octet unsigned integer indicates the Autonomous System number of the sender. Peer Autonomous System: This 2-octet unsigned integer indicates the Autonomous System number of the intended receiver. Wu, et al. Expires August 11, 2007 [Page 24] Internet-Draft E2E SAVA Solution for IPV6 February 2007 Action ID Parameter: This 4-octet unsigned integer indicates the action ID parameter for this request. It's the latest action ID that requesting ASC getting from the peer ASC. If the ASC wants to get the information of all prefix list, the value should be set to 0. 8.2.2. PREFIX_REQ_ACK Message Formats After one ASC receives PREFIX_REQUEST message from the other ASC, if the request is valid, the ASC will send back PREFIX_REQ_ACK message The PREFIX_REQ_ACK message contains the following fields: 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 +-+-+-+-+-+-+-+-+ | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Data Records | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Action ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Records (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Command: This 1-octet unsigned integer indicates the type code of the message. For PREFIX_REQ_ACK message, the command value is 6. Number of Data Records: This 4-octet unsigned integer indicates the number of the total records returned. Last Action ID: This 4-octet unsigned integer indicates the latest action ID of the records returned. Data Records: This is a variable length field that contains a list of the prefix list information. Each prefix list info record contains the following field: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Address (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Flag | Last Action | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Address: This 16-octet data indicates the address of the IPv6 prefix. Wu, et al. Expires August 11, 2007 [Page 25] Internet-Draft E2E SAVA Solution for IPV6 February 2007 Prefix Length: This 1-octet unsigned integer indicates the length of the prefix. Flag: This is 1-octet unsigned integer indicates the flag for this prefix. The meaning of the flag field for a prefix has been discussed in Section 5.3. The value of this field may be: o 1: this prefix belongs to this AS member. o 0: this prefix does not belongs to this AS member. Last Action: This is 1-octet unsigned integer indicates the last action for this prefix. The value of this field may be: o Add(1): last action is "add" for this prefix. o Delete(0): last action is "delete" for this prefix. 8.2.3. PREFIX_REQ_NAK Message Formats After one ASC receives PREFIX_REQUEST message from the other ASC, if the request is invalid, the ASC will send back PREFIX_REQ_NAK message to the other ASC. The PREFIX_REQ_NAK message contains the following fields: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Command: This 1-octet unsigned integer indicates the type code of the message. For PREFIX_REQ_NAK message, the command value is 7. Error Code: This 1-octet unsigned integer indicates the error type in processing this request. The value of the error code may be: o 1: invalid AS number. The AS that sends the request to the ASC is not in the E2E Alliance member list at local AS. o 2: invalid ASC address. The address of the sending host does not match the address in the E2E Alliance member list. o 3: invalid peer AS number. The "Peer Autonomous System" field in the PREFIX_REQUEST does not match the local AS number. Wu, et al. Expires August 11, 2007 [Page 26] Internet-Draft E2E SAVA Solution for IPV6 February 2007 8.2.4. PREFIX_NOTIF Message Formats If there are some update to the local prefix list at the ASC, this ASC should send PREFIX_NOTIF message to ASC of all the AS member in the E2E Alliance. The PREFIX_NOTIF message contains the following fields: 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 +-+-+-+-+-+-+-+-+ | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Latest Action ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Command: This 1-octet unsigned integer indicates the type code of the message. For PREFIX_NOTIF message, the command value is 8. My Autonomous System: This 2-octet unsigned integer indicates the AS number of the AS member that sending this message. Latest Action ID: This 4-octet unsigned integer indicates the action ID of lastest update to the prefix list at the sending ASC. 8.2.5. SIG_OUT_NOTIF Message Formats If one ASC wants to change its incoming direction signature with the other AS member, it sends SIG_OUT_NOTIF message to the ASC of the other AS member. The PREFIX_NOTIF message contains the following fields: 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 +-+-+-+-+-+-+-+-+ | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | Peer Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Sequence of Signature | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Signature (6 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Command: This 1-octet unsigned integer indicates the type code of the Wu, et al. Expires August 11, 2007 [Page 27] Internet-Draft E2E SAVA Solution for IPV6 February 2007 message. For SIG_OUT_NOTIF message, the command value is 9. My Autonomous System: This 2-octet unsigned integer indicates the Autonomous System number of the sender. Peer Autonomous System: This 2-octet unsigned integer indicates the Autonomous System number of the intended receiver. Sequence of Signature: This 4-octet unsigned integer indicates the sequence of the signature in this message. Signature: This 6-octet data indicates the signature suggested by the sending ASC. 8.2.6. SIG_OUT_OK Message Formats After one ASC receives SIG_OUT_NOTIF message from the other AS member, it should change the out-going direction signature with the other AS member. The procedure of changing of the signature (including change the configuration at edge routers) may take some time. After this procedure is finished, the ASC sends SIG_OUT_OK message to the other AS member. The SIG_OUT_OK message contains the following fields: 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 +-+-+-+-+-+-+-+-+ | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | Peer Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence of Signature | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Command: This 1-octet unsigned integer indicates the type code of the message. For SIG_OUT_OK message, the command value is 10. My Autonomous System: This 2-octet unsigned integer indicates the Autonomous System number of the sender. Peer Autonomous System: This 2-octet unsigned integer indicates the Autonomous System number of the intended receiver. Sequence of Signature: This 4-octet unsigned integer indicates the sequence of the signature in this message. It is derived from last SIG_OUT_NOTIF message received. Wu, et al. Expires August 11, 2007 [Page 28] Internet-Draft E2E SAVA Solution for IPV6 February 2007 8.2.7. SIG_KEEPALIVE Message Formats The SIG_KEEPALIVE message contains the following fields: 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 +-+-+-+-+-+-+-+-+ | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Autonomous System | Peer Autonomous System | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Command: This 1-octet unsigned integer indicates the type code of the message. For SIG_OUT_OK message, the command value is 11. My Autonomous System: This 2-octet unsigned integer indicates the Autonomous System number of the sender. Peer Autonomous System: This 2-octet unsigned integer indicates the Autonomous System number of the intended receiver. 8.3. Procedure for Prefix Information Exchange The way that ASC spreads prefix information is quite similar to the way that REG spreads E2E Alliance member list information. There are two possible ways of exchanging the prefix information. First, an ASC may initiate sending a request to another ASC to get its local prefix list information. Sencond, when some modification is made at an ASC, it should notifify all other ASC of the E2E Alliance about this modification. 8.3.1. ASC Initiate Request to Another ASC An ASC (e.g., ASC_A) may send request to another ASC (e.g., ASC_B) to get its prefix list. For the ASC that sends the request, the procedure is as follows: 1. ASC_A connects to ASC_B. 2. ASC_A sends PREFIX_REQUEST message to ASC_B. If ASC_A only wants to get the update information, the Action ID Parameter in the message may be the Last Action ID got from the last PREFIX_REQ_ACK message received from ASC_B; if ASC_A wants to get the whole prefix list of ASC_B, the Action ID Parameter should set to be zero. 3. ASC_A receives PREFIX_REQ_ACK message or PREFIX_REQ_NAK message from ASC_B. Wu, et al. Expires August 11, 2007 [Page 29] Internet-Draft E2E SAVA Solution for IPV6 February 2007 4. ASC_A closes the connection. For the ASC that receives the request, the procedure is as follows: 1. ASC_B accepts the connection request from ASC_A. 2. ASC_B receives INFO_REQUEST message from the ASC. 3. ASC_B validates the AS number in "Peer Autonomous System" field in the PERFIX_REQUEST message. If the AS number does not match the AS number of ASC_B, ASC_B sends PREFIX_REQ_NAK message with error code set to be "invalid peer AS number", and ASC_B closes the connection; else, go to the next step. 4. ASC_B validates the AS number in "My Autonomous System" field. If the AS number is not in the E2E Alliance member list, ASC_B sends PREFIX_REQ_NAK message with error code set to be "invalid AS number", and ASC_B closes the connection; else, go to the next step. 5. ASC_B validates the peer address of connection. If the address does not match with the record in the E2E Alliance member list, ASC_B sends PREFIX_REQ_NAK message with error code set to be "invalid ASC address", and ASC_B closes the connection; else, go to the next step. 6. ASC_B sends INFO_REQ_ACK message to ASC_B, with the requested prefix list information. 7. ASC_B closes the connection. 8.3.2. ASC Initiate Notification to other ASCs When some changes are made to the prefix list at the ASC, ASC should send notification to other ASC of all the member in the E2E Alliance member list. Suppose there is some changes at prefix list of ASC_A, and ASC_A notifies it to ASC_B. For ASC_A, the procedure is as follows: 1. ASC_A connects to ASC_B. 2. ASC_A sends PREFIX_NOTIF message to ASC_B. 3. ASC_A close the connection. For ASC_B, the procedure is as follows: Wu, et al. Expires August 11, 2007 [Page 30] Internet-Draft E2E SAVA Solution for IPV6 February 2007 1. ASC_B accepts connection request from ASC_A. 2. ASC_B receives PREFIX_NOTIF message from ASC_A. 3. ASC_B validates the AS number in "My Autonomous System" field. If the AS number is not in the E2E Alliance member list, ASC_B closes the connection; else, go to the next step. 4. ASC_B validates peer address of the connection. If the address does not match with the record in the E2E Alliance member list, ASC_B closes the connection; else, go to the next step. 5. ASC_B compares the Latest Action ID in PREFIX_NOTIF message with the Last Action ID got from last PREFIX_REQ_ACK message. received. If the action ID in PREFIX_NOTIF message is more recent, ASC_B sends request to ASC_A as described in Section 8.3.1; else, ASC_B makes no action. 8.4. Procedure for Signature Information Exchange 8.4.1. Overview A pair of signatures can be set up between two AS members in the Alliance. Each signatue is only used for the one direction traffic between the two ASes. An AS member can decide whether signature is applied for its incoming traffic, and decides when to change the signature and how to change the signature. This makes one AS control its own incoming traffic. The AS that sending traffic to this AS should modify its signature for out-going traffic in response to the request from the receiving AS. +----------+ Sig-21 +----------+ | |<----------------| | | AS-1 | Sig-12 | AS-2 | | |---------------->| | +----------+ +----------+ As suggested in [Bre05], the signature used between two AS should be changed periodically. We need to design the mechanism to smoothly change the signature. Also, there may be cases that the synchronization for the signature between ASes is broken. We need to design some mechanism to detect and cure such out of synchronization. Wu, et al. Expires August 11, 2007 [Page 31] Internet-Draft E2E SAVA Solution for IPV6 February 2007 8.4.2. Procedure of Managing the Signature Here the procedure for managing the signature of one direction traffic is decribed. We'll describe how to manage the signature for the direction from AS-2 to AS-1. ASC-1 is the AS Control Server of AS-1. AER-1 is the edge router of AS-1. Of course, AS-1 may have more than one edge routers. AER-1 is only a representative of all edge routers of AS-1. Similarly, ASC-2 is the AS Control Server of AS-1, and AER-2 is the edge router of AS-2. +----------+ +----------+ | | Sig-21 | | | ASC-1 |<--------------------| ASC-2 | | | | | +----------+ +----------+ /|\ /|\ | | \|/ \|/ +------+ +------+ |AER-1 | |AER-2 | +------+ +------+ AS-1 AS-2 8.4.2.1. Start to Use the Signature At the start, there is no signature set up for the traffic from AS-2 to AS-1. Then AS-1 decides to set up the signature. The procedure is as follows: 1. ASC-1 generates one 48-bit signature. 2. ASC-1 sends the signature configuration AER-1. The state of this signature on the edge router is Start, the edge router can accept a packet from AS-2 without any signature, or with the signature. 3. ASC-1 waits for the finish of signature configuration at AER-1. If the configuration is finished at AER-1, AER-1 sends a notification to ASC-1. 4. After the signature has been configured to all the edge routers in AS-1, ASC-1 sends SIG_OUT_NOTIF message to ASC-2. 5. ASC-2 validates the SIG_OUT message received. Then it configures the signatue to all edge routers in AS-2. 6. After the signature has been configured to all the edge routers in AS-2, ASC-2 sends SIG_OUT_OK message to ASC-1. Wu, et al. Expires August 11, 2007 [Page 32] Internet-Draft E2E SAVA Solution for IPV6 February 2007 7. ASC-1 changes the state of this signature on all edge routers to Single. The edge router can only accept packet with this signature from AS-2. In the above procedure, the communication between two ASCs is based on TCP connection. 8.4.2.2. Periodically Change the Signature After some time interval, ASC-1 will change the signature. The procedure is as follows: 1. ASC-1 generates a new signature. 2. ASC-1 sends the signature configuration AER-1. The state of this signature on the edge router is Switching, the edge router can accept a packet from AS-2 without the old signature, or with the new signature. 3. ASC-1 waits for the finish of signature configuration at AER-1. If the configuration is finished at AER-1, AER-1 sends a notification to ASC-1. 4. After the signature has been configured to all the edge routers in AS-1, ASC-1 sends SIG_OUT_NOTIF message to ASC-2. 5. ASC-2 validates the SIG_OUT message received. Then it configures the new signatue to all edge routers in AS-2. 6. After the new signature has been configured to all the edge routers in AS-2, ASC-2 sends SIG_OUT_OK message to ASC-1. 7. ASC-1 changes the state of this signature on all edge routers to Single. The edge router can only accept packet with the new signature from AS-2. In the above procedure, the communication between two ASCs is based on TCP connection. 8.4.2.3. Handle Out of Synchronization of the Signature The synchronization of signature (i.e., the state of the signature at the sending AS and the receiving AS is synchronized) between two ASes may be broken. So there must be some mechanism to detect this situation and recover from this situation. After the signature is set up at the sending AS, the ASC of the sending AS should periodically send SIG_KEEPALIVE message to the ASC Wu, et al. Expires August 11, 2007 [Page 33] Internet-Draft E2E SAVA Solution for IPV6 February 2007 of receiving AS. The SIG_KEEPALIVE message is sent over UDP protocol. If the receiving AS does not receive SIG_KEEPALIVE message from the sending AS for a specific time interval, the receiving AS deduces that the signature for the traffic from the sending AS to the receiving AS is broken. It should set the state of the signature to Start, and repeat the procedure specified in Section 8.4.2.1. SIG_KEEPALIVE is only sent when the state of signature at the receiving AS is Single or Switching. In these two states, the incoming traffic is protected by the signature, so SIG_KEEPALIVE with spoofed source address can not be delivered to the ASC of the receiving AS. 8.4.3. FSM for the Incoming Direction Signature To clarify the management of the signature, we design a Finite State Machine for the incoming direction signature. The states and the events in this FSM are as follows: Incoming Signature States: 1 - None 2 - Start 3 - Single 4 - Switching Incoming Signature Sub-state (for state Start and Switching): 1 - Wait-Local-Conf 2 - Wait-Peer-Conf Incoming Signature Events: 1 - Start command 2 - Local configuration finished 3 - Receive SIG_OUT_OK message 4 - Sig-Switching timer expires 5 - Keep-Alive detection fails For state Start and Switching, two sub states are defined. Wait- Local-Conf is the state that ASC of receiving AS is waiting for the signature to be configured to the local edge routers. Wait-Peer-Conf is the state that ASC of receiving AS is waiting for the signature to be configured to the edge routers in the peer AS. The transition of the state (not include the sub states) is depicted as follows: Wu, et al. Expires August 11, 2007 [Page 34] Internet-Draft E2E SAVA Solution for IPV6 February 2007 +----------+ | | | None | | | +----------+ | | (1) \|/ +----------+ (2, 3) +----------+ (4) +----------+ | |--------->| |--------->| | | Start | | Single | | Switching| | |<---------| |<---------| | +----------+ (5) +----------+ (2, 3) +----------+ The transition of the state (include sub states) is also depicted in the following table: Event Actions Message Sent Next State -------------------------------------------------------------------- None (1) 1 Generate incoming direction none 2.1 signature. Start to set signature to all edge routers of local AS. Start(2) Wait-Local-Conf(2.1) 2 none SIG_OUT 2.2 Wait-Peer-Conf(2.2) 3 Start sig-Switching timer none 3 Single (3) 4 Generate incoming direction none 4.1 signature. Start to set signature to all edge routers of local AS. 5 Generate incoming direction 2 signature. Start to set signature to all edge routers of local AS. Switching (4) Wait-Local-Conf(4.1) 2 none SIG_OUT 4.2 Wait-Peer-Conf(4.2) Wu, et al. Expires August 11, 2007 [Page 35] Internet-Draft E2E SAVA Solution for IPV6 February 2007 3 Start sig-Switching timer none 3 Wu, et al. Expires August 11, 2007 [Page 36] Internet-Draft E2E SAVA Solution for IPV6 February 2007 9. Other Discussion 9.1. Coexist with IPSEC The deployment of this method will not break the communication with IPSEC. Though this method will change the packet at the sending AS, it will modify it back to its original packet. So it will not break IPSEC. 9.2. Difference from IPSEC Someone may ask why we don't build secure tunnel between two ASes with IPSEC, instead of using E2E mechanism. We agree that the basic mechanism of IPSEC and this method are similar, i.e., applying end- to-end signature to assure the identity of the source. But this method is different from IPSEC at the following aspects: o The two ends of an IPSEC tunnel are identified by IP address, while with this method the two ends are AS networks. An AS network may have more than one entrance interface. So it is unsuitable to use IPSEC between two ASes. o This method is used between ASes, usually with high bandwidth links, so it should be simplified. While IPSEC is still too complex for processing high bandwidth link. 9.3. The Overhead of Communication Between AS Members The overhead of maintain E2E Alliance is not O(N^2), but O(N). Also, the traffic for exchanging the signature and the prefix for an AS member is acceptable. Each AS may decide whether to exchange prefix and signature with other AS member. Each AS can decides whether to secure the incoming direction from one other AS member. If this AS decide to do so, it can request prefix list information from other AS member, and negotiate incoming direction signature with other AS member. 9.4. Method For Guessing the Signature The method for guessing the signature between two AS members has been described in [Bre05]. For the convinience of the reader to understand the problem, we also describe it here. If an attacker wants to send attacking traffic to AS-1 with spoofed source address of AS-2, he should control at least one host in AS-2. He should also control at least one host C in a network that doesn't Wu, et al. Expires August 11, 2007 [Page 37] Internet-Draft E2E SAVA Solution for IPV6 February 2007 deploy this mechanism. Host C can send ICMP Echo Request packet to one host A in AS-1, with the source address of host B. C can change the signature in the packet. If host B receives ICMP Echo Response from host A, the attacker can decide that the signature in the corresponding ICMP Echo Request packet is the one he wants to get. +-----+ | C | +-----+ ,-------------- ,-------------- ,' ` `. ,' ` `. / \ / \ / \ / \ ; +-----+ ; ; +-----+ ; | | A | | | | B | | : +-----+ : : +-----+ : \ / \ / \ / \ / `. ,' `. ,' '-------------' '-------------' AS-1 AS-2 The authors of [Bre05] suggested to use 32-bit signature. But we change to use another view-point to study this problem, and decide that 32- bit is still not enough. The attacker may control hundreds or even more hosts in the network without deployment of this method. Suppose the attacker controls 1 giga bandwidth to the destination AS (it is not very difficult for a large AS), and suppose the size of ICMP Echo Request packet sent by the attacker is 64-byte long. In the worst case, it only takes the attacker about 30 minutes to get the right signature. Considering that the link capacity will increase a lot in the near future, we suggest to use longer signature. Wu, et al. Expires August 11, 2007 [Page 38] Internet-Draft E2E SAVA Solution for IPV6 February 2007 10. Future Work Some issues to be worked on are: o The design of the message is still very simple. There is possibility that transmission of message over TCP connection fails, and such mechanism like the design in BGP [RFC1654] should be added. o Signature generation algorithm. How to generate the 48-bit signature is not decided yet. o How to process ICMP "Packet Too Big" packets by the AS edge routers. The AS edge routers should decrease the MTU field in the ICMP "Packet Too Big" packets. Wu, et al. Expires August 11, 2007 [Page 39] Internet-Draft E2E SAVA Solution for IPV6 February 2007 11. IANA Considerations A new type of option in Hop-by-Hop Options Header is defined in Section 5.1. A new type of IPv6 extension header is defined in Section 5.1. A special TCP port should be allocated for listening at Registration Server and AS Control Server. A special UDP port should be allocated for listen at the AS Control Server to receive Keep-alive packets. Wu, et al. Expires August 11, 2007 [Page 40] Internet-Draft E2E SAVA Solution for IPV6 February 2007 12. Security Considerations Wu, et al. Expires August 11, 2007 [Page 41] Internet-Draft E2E SAVA Solution for IPV6 February 2007 13. Acknowledgements The authors would like to acknowledge the contributors who provided helpful inputs on earlier versions of this document. Wu, et al. Expires August 11, 2007 [Page 42] Internet-Draft E2E SAVA Solution for IPV6 February 2007 14. References [Bre05] Bremler-Barr, A. and H. Levy, "Spoofing Prevention Method", Infocom 2005, 2005. [I-D.bellovin-itrace] Bellovin, S., "ICMP Traceback Messages, draft-bellovin-itrace-00", May 2000. [Li02] Li, J., Mirkovic, J., Wang, M., Reiher, P., and L. Zhang, "SAVE: Source Address Validity Enforcement Protocol", Infocom 2002, 2002. [RFC1654] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1654, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 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. Wu, et al. Expires August 11, 2007 [Page 43] Internet-Draft E2E SAVA Solution for IPV6 February 2007 Authors' Addresses Jianping Wu CERNET Network Center, Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Jun Bi CERNET Network Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Xing Li CERNET Network Center, Tsinghua University Beijing 100084 China Email: xing@cernet.edu.cn Mingjiang Ye CERNET Network Center, Tsinghua University Beijing 100084 China Email: yemingjiang@csnet1.cs.tsinghua.edu.cn Wu, et al. Expires August 11, 2007 [Page 44] Internet-Draft E2E SAVA Solution for IPV6 February 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). Wu, et al. Expires August 11, 2007 [Page 45]