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