One document matched: draft-wu-sava-solution-e2e-ipv6-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 19:40:00 |