RFC 5210
A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience
RFC 5210: A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience 💖
okay bestie, so this one is RFC 5210 🎀 It's an Experimental doc (not a standard, just a test-drive 🧪), from the Network Working Group and dated June 2008. The authors are J. Wu, J. Bi, X. Li, G. Ren, and K. Xu from Tsinghua University, plus M. Williams from Juniper Networks. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨
Status of This Memo 📋
this memo defines an Experimental Protocol for the Internet community 🧪 it does not specify an Internet standard of any kind. discussion and suggestions for improvement are requested 🫶 distribution of this memo is unlimited 🌈
Abstract 🌸
so the Internet forwards packets by looking at the IP destination address 📬 which means the source address usually doesn't get checked on the way through, and attackers have totally been spoofing their source addresses to launch attacks 💀 to fix that, a prototype of the IP Source Address Validation Architecture (SAVA) got built and tested on an IPv6 network 🔥 this doc is the report: the prototype, the test results, and the lessons learned from experimenting 🧠
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A Prototype SAVA Implementation . . . . . . . . . . . . . . . 4
2.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 4
2.2. IP Source Address Validation in the Access Network . . . . 6
2.3. IP Source Address Validation at Intra-AS/Ingress Point . . 9
2.4. IP Source Address Validation in the Inter-AS Case
(Neighboring AS) . . . . . . . . . . . . . . . . . . . . . 9
2.5. IP Source Address Validation in the Inter-AS Case
(Non-Neighboring AS) . . . . . . . . . . . . . . . . . . . 12
3. SAVA Testbed . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. CNGI-CERNET2 . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. SAVA Testbed on CNGI-CERNET2 Infrastructure . . . . . . . 16
4. Test Experience and Results . . . . . . . . . . . . . . . . . 17
4.1. Test Scenarios . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Test Results . . . . . . . . . . . . . . . . . . . . . . . 18
5. Limitations and Issues . . . . . . . . . . . . . . . . . . . . 18
5.1. General Issues . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 20
5.3. Protocol Details . . . . . . . . . . . . . . . . . . . . . 20
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 231. Introduction ✨
okay so by design, the Internet forwards data packets based solely on the destination IP address 📦 the source IP address doesn't get checked during forwarding in most cases 😭 which makes it super easy for shady hosts to fake the source address on their packets 👀 we think it'd be really useful to enforce source IP address validity for all the packets being forwarded 💅
enforcing source IP address validity would help us hit these goals:
- Attack-proofing 🛡️ since packets with spoofed source addresses wouldn't get forwarded, it'd be impossible to launch network attacks that depend on spoofed source addresses 🙅♀️ and it'd be way harder to pull off attacks that get boosted or strengthened by spoofing 💀
- Traceback that actually works 🔍 if you can assume every packet's source address is correct, traceback can be done accurately and with real confidence 🎯 that would help with network diagnosis, management, accounting, and applications, which is giving main character energy 👑
as part of developing a Source Address Validation Architecture (SAVA), we implemented a SAVA prototype and deployed it in 12 ASes in an operational network as part of the China Next Generation Internet (CNGI) Project [Wu07] 🇨🇳 we ran evaluation experiments 🧪 in this doc, we first describe the prototype solutions and then report the experimental results 📊 we hope this doc gives useful insights to anyone interested in the topic and can serve as an initial input to future IETF work in this area 🫶
there've been a bunch of research and engineering efforts to design IP source address validation mechanisms, like [RFC2827], [Park01], [Li02], [Brem05], and [Snoe01] 📚 our SAVA prototype was inspired by some of the schemes from those proposed or existing solutions 💜
ngl, the prototype and the experimental results in this report only serve as an input 🙏 they in no way preempt any solution development that future IETF work might do 🌸 the solutions here are experimental approaches with a number of limitations, which are discussed in Sections 5 and 6 🥹
2. A Prototype SAVA Implementation 🎀
2.1. Solution Overview 🦋
okay so this doc proposes a multiple-fence solution 🚧 basically there are multiple points in the network where a packet's source address validity can get checked 🔐 why? because in the current single-fence model, source address validity is basically only checked at ingress to the network 😬 and deployment has been so inadequate that there's always enough room to mount attacks based on spoofed source addresses 💀 it seems likely this will keep being true for the foreseeable future 🙃 a multiple-fence solution lets us cover the "holes" in deployment and evaluate source address validity with more confidence across the whole Internet 🌍 the assumption here is that even when validity checking isn't universal, it's still worth increasing confidence in source address validity and cutting down the chances to spoof 🫶
also, the architecture allows for multiple independent and loosely-coupled checking mechanisms 🧩 the reason is that across the Internet at large, it's unrealistic to expect any single IP source address validation mechanism to be universally supported 😤 different operators and vendors may want to deploy or develop different mechanisms to get the same end result, and different places in the network need different mechanisms to solve the problem 🍓 plus, implementation bugs or configuration errors could make an implementation ineffective 😭 so our prototype SAVA implementation is a combo of multiple coexisting and cooperating mechanisms 💖 specifically, we implement source IP address validation at three levels: access network SAV, intra-AS SAV, and inter-AS SAV, as shown in Figure 1 🎨 the system details can be found in [Wu07] ✨
__ ____ __ ____
.-'' `': .-'' `':
| | | |
| +-+----+ | Inter-AS SAV | +-+----+ |
| |Router+--+------------------+---|Router+ +
| +--.---+ | | +--.---+ |
Intra-AS | | \ Intra-AS | | |
SAV | +--+---+ \ SAV | +--+---+ |
| |Router| \ | |Router| |
| +--.---+ \ '_ +-----+ _
| | \ `'-------'''
/ | \
/ | \
| +---------------------+\
----+---------. Router | \
| ++-------\------------+ \
| | | \ | | |
| | +------+|+------++----+|Intra-AS
| | |Switch|||Switch||Host||SAV
| | +------+|+------++----+|
| | | | | \ |
|+-+--++----+|+----++----+ |
||Host||Host|||Host||Host| |
`+----++----+|+----++----+ /
`--. | _.-'
`------|------+''
Access |
Network |
SAV
Key: SAV - Source Address Validation
Figure 1: Solution Overviewthis doc splits source address validation into three classes of solutions 🍰
- Access network 🏠 this stops a host in a network from spoofing the address of another host in the same network segment 🙅 it gives you host-granularity protection, which is way more precise than Intra-AS prevention 🎯 see Section 2.2 for the deets 📖
- Intra-AS 🏢 when the edge router of an access network does source address validation (for example, using [RFC2827] and [RFC3704]), hosts can't spoof just any arbitrary address 🙌 but unless access network SAV is in place, they might still be able to spoof the address of a host in the same network segment 😬 in a degenerate case, where a router connects a single host, that host can't spoof any address at all 🧚
- Inter-AS 🌐 these are mechanisms that enforce packet source address correctness at AS boundaries 🛂 because the global Internet is a mesh topology and different networks belong to different administrative authorities, IP source address validation at the Inter-AS level is way more challenging 🥵 still, we believe this third level of protection is necessary to catch packets with spoofed source addresses when the first two levels are missing or ineffective 🫡
in the following sections, we break down the specific mechanisms implemented at each of those three levels in detail 💅✨
2.2. IP Source Address Validation in the Access Network ✨
okay bestie, at the access network level the goal is simple: a host inside the network cannot borrow another host's source address 🙅♀️ The address a host uses should be a valid one assigned to it, either statically or dynamically. The experiment's solution does this for Ethernet networks 🔌
Here's the setup. A layer-3 SAVA Device sits at the exit of the access network 🚪 It can be a function inside the Customer Premises Equipment (CPE) router, or its own separate box. SAVA Agents live inside the access network. Fun fact: they could even just be a function in the first hop router or switch connected to the hosts 🧚 A set of protocols handles the chat between host, SAVA Agent, and SAVA Device. The main vibe? Only a packet from the host that was actually assigned that particular source address gets through the SAVA Agent and SAVA Device 💅
There are two deployment variants, called Variant A and Variant B 🦋
Variant A is all about the agent. The agent is mandatory, and each host is plugged into it on a dedicated physical port 🔒 The key function here is making a dynamic binding between a switch port and a valid source IP address, or a binding between a Media Access Control (MAC) address, source IP address, and switch port. In the prototype, hosts use a new address configuration protocol that the switch is able to track 👀
Note: In a production environment, the approach in the prototype would not be sufficient, due to reasons discussed in Section 5. Bestie, read Section 5 before you get any ideas 🙈
In Variant A there are three main participants: the Source Address Request Client (SARC) on the host, the Source Address Validation Proxy (SAVP) on the switch, and the Source Address Management Server (SAMS), as shown in Figure 2 💖 Here's the flow:
- The SARC on the end host sends an IP address request. The SAVP on the switch relays this request to the SAMS and records the MAC address and incoming port. If the end host has already predetermined the address, it still needs to put that address in the request message so the SAMS can verify it 📝
- After the SAMS receives the IP address request, it allocates a source address for that SARC based on the address allocation and management policy of the access network. It stores the allocation in the SAMS history database for traceback, then sends a response message containing the allocated address to the SARC 🗂️
- After the SAVP on the access switch receives the response, it binds the IP address and the previously stored MAC address from the request message to the switch port in the binding table. Then it forwards the issued address to the SARC on the end host 🎀
- The access switch starts filtering packets sent from the end host. Packets that don't conform to the tuple (IP address, Switch Port) get discarded 🗑️
----------------
| SERVER |
| ------- |
| | SAMS | |
| -------- |
-----------------
|
|
----------------
| SWITCH |
| ------- |
| | SAVP | |
| -------- |
-----------------
|
|
----------------
| END HOST |
| ------- |
| | SARC | |
| -------- |
-----------------
Key: SARC - Source Address Request Client
SAVP - Source Address Validation Proxy
SAMS - Source Address Management Sever
Figure 2: Binding-Based IP Source Address Validation
in the Access NetworkNow Variant B 🌈 The main idea is to use key material from network access authentication for an extra validation step. A session key is derived for each host connecting to the network, and every packet the host sends carries cryptographic protection using that session key 🔐 Once you know which host a packet came from, you can track whether the addresses allocated to that host match the ones it's actually using. The mechanism details are in [XBW07], but the process follows these basic steps:
- When a host wants to establish connectivity, it needs to perform network access authentication 🪪
- The network access devices provide the SAVA Agent (often co-located) a session key S. This key is further distributed to the SAVA Device, which binds the session key and the host's IP address 🔑
- When the host sends packet M to somewhere outside the access network, either the host or the SAVA Agent needs to generate a message authentication code for each one, using key S and packet M. In the prototype, the message authentication code is carried in an experimental IPv6 extension header 🧪
- The SAVA Device uses the session key to authenticate the signature carried in the packet, so that it can validate the source address ✅
We implemented and tested both solutions in our testbed 🧪 The switch-based solution has better performance, but the switches in the access network would need to be upgraded, and since the number of switches in an access network is usually large, that's a lot of upgrading 😭 The signature-based solution could be deployed between the host and the exit router, but it has some extra cost for inserting and validating the signature 💀
2.3. IP Source Address Validation at Intra-AS/Ingress Point 🌸
We adopted the source address validation of IP packets at ingress points described in [RFC2827] and [RFC3704] 🫶 The latter describes source address validation at the ingress points of multi-homed access networks, so it's a super relevant match for our setup 👑
2.4. IP Source Address Validation in the Inter-AS Case (Neighboring AS)
okay bestie, so the inter-AS SAVA design had two big vibes it needed to hit ✨. First, it has to cooperate across ASes with different administrative authorities and different interests 🤝. Second, it should be lightweight enough to support high throughput and not mess with forwarding efficiency 🚀.
Inter-AS SAVA splits into two sub-cases 🎀:
- Two SAVA-compliant ASes exchanging traffic are directly connected;
- Two SAVA-compliant ASes are separated by one or more intervening, non-SAVA-compliant providers.
Here's the picture 🦋:
---------
| AIMS |
------|-
|
-------------- -----------|-----
| AS-4 |-------- --------| AS-1 | |------- Global
| ------ |ASBR,VE|->|ASBR,VE| ------|- |ASBR,VE|--->IPv6
| |VRGE| |-------- --------| | VRGE | |------- Network
| ------ | | -------- |
--------------- ----- -----------------
|ASBR,VE| |ASBR,VE|
--------- ---------
/ |
/ |
/ |
/ |
---------- --------
|ASBR, VE| |ASBR,VE|
--------------- -------------
| AS-2 | | AS-3 |
| ----- | | ----- |
| |VRGE| | | |VRGE| |
| ----- | | ------ |
--------------- -------------
Key: AIMS - AS-IPv6 prefix Mapping Server
ASBR - AS Border Router
VE - Validating Engine
VR - Validation Rule
VRGE - Validation Rule Generating EngineFigure 3: Inter-ISP (Neighboring AS) Solution
Two ASes that swap traffic can have a customer-to-provider, provider-to-customer, peer-to-peer, or sibling-to-sibling relationship 💅. In a customer-to-provider or provider-to-customer setup, the customer typically belongs to a smaller admin domain that pays a bigger one for access to the rest of the Internet, and that bigger one is the provider 💸. In peer-to-peer, the two peers typically have comparable-sized admin domains and find it mutually advantageous to swap traffic between their respective customers 🤝. Two ASes are sibling-to-sibling if they're in the same admin domain or in domains with a mutual-transit agreement 🫶.
The neighboring-AS mechanism is AS-relation-based 🔥. The basic idea is that it builds a VR table linking each incoming interface of a router to a set of valid source address blocks, and then uses that table to filter spoofed packets 🧚.
On the testbed, validating IPv6 prefixes is split into three functional modules 💜: the Validation Rule Generating Engine (VRGE), the Validation Engine (VE), and the AS-IPv6 prefix Mapping Server (AIMS). Validation rules made by the VRGE are expressed as IPv6 address prefixes. Each AS has a VRGE, which generates validation rules derived according to Table 1 🌸. The VE loads those rules to filter packets passed between ASes (in Figure 3, from neighboring ASes into AS-1). In the SAVA testbed, the VE is a simulated layer-2 device on a Linux-based machine, slotted into the data path just outside each ASBR interface that faces a neighboring AS. In a real-world setup, it would probably be a packet-filtering set on the ASBR 🛠️. The AS-IPv6 prefix mapping server also runs on a Linux machine and derives a mapping between an IPv6 prefix and the AS number of that prefix 🗺️.
----------------------------------------------------------------------
| \Export| Own | Customer's| Sibling's | Provider's | Peer's |
|To \ | Address | Address | Address | Address | Address |
|-----\--------------------------------------------------------------|
| Provider | Y | Y | Y | | |
|--------------------------------------------------------------------|
| Customer | Y | Y | Y | Y | Y |
|--------------------------------------------------------------------|
| Peer | Y | Y | Y | | |
|--------------------------------------------------------------------|
| Sibling | Y | Y | Y | Y | Y |
----------------------------------------------------------------------Table 1: AS-Relation-Based Inter-AS Filtering
Different ASes exchange and transmit VR info using the AS-Relation-Based Export Rules in the VRGE 📤. Per Table 1, an AS exports the address prefixes of itself, its customers, its providers, its siblings, and its peers to its customers and siblings as valid prefixes. But it only exports the prefixes of itself, its customers, and its siblings to its providers and peers as valid prefixes 👑. With the help of the AS-IPv6 prefix mapping server, only AS numbers of valid prefixes get transferred between ASes, and the VRGE maps those AS numbers back to address prefixes 🧩.
Only changes of AS relation and changes of IP address prefixes belonging to an AS require VR updates to be generated 🔄.
The procedure's main steps go like this (starting from AS-1 in Figure 3) ✨:
- When the VRGE has initialized, it reads its neighboring SAVA-compliant AS table and establishes connections to all the VEs in its own AS 🔌.
- The VRGE initiates a VR renewal. According to its export table, it sends its own originated VR to VRGEs of neighboring ASes. In this process, VRs are expressed as AS numbers 📨.
- When a VRGE receives a new VR from its neighbor, it uses its own export table to decide whether it should accept the VR and, if it accepts a VR, whether or not it should re-export the VR to other neighboring ASes 🤔.
- If the VRGE accepts a VR, it uses the AIMS to transform the AS-expressed VR into an IPv6 prefix-expressed VR 🔁.
- The VRGE pushes the VR to all the VEs in its AS 🚀.
The VEs use these prefix-based VRs to validate the source IP addresses of incoming packets, and that's the whole vibe 💅🫶
2.5. IP Source Address Validation in the Inter-AS Case (Non-Neighboring AS) 🦋
okay so this one is for when two ASes don't exchange packets directly 🌸 in that case you can't use the setup from the last section, no cap. but it's highly desirable for non-neighboring ISPs to form a trust alliance, so that packets leaving one AS get recognized by the other and keep the validation status they had when they left the first AS 💅 there's more than one way to do this. for the SAVA experiments so far, they used an authentication tag method, which is inspired by the work of [Brem05] ✨
the key pieces of this lightweight authentication tag mechanism go like this 🎀 for every pair of SAVA-compliant ASes, there's a pair of unique temporary authentication tags. all the SAVA-compliant ASes together form a SAVA AS Alliance 👑 when a packet is leaving its own AS and the destination IP address belongs to an AS in the SAVA AS Alliance, the edge router of that AS looks up the authentication tag using the destination AS number as the key, and adds the tag to the packet. when a packet arrives at the destination AS and its source address belongs to an AS in the SAVA AS Alliance, the destination AS's edge router searches its table for the tag using the source AS number as the key, then verifies the tag carried in the packet and removes it 🫶
as the name says, this method uses a lightweight authentication tag 🧚 for every packet forwarded, the tag can go in an IPv6 hop-by-hop extension header. it's reasonable to use a 128-bit shared random number as the tag, which saves processing overhead compared to generating the tag with a cryptographic method 🌈
now, why bother with all this when you could just turn on local address validation (like RFC 2827)? ngl it's a total glow-up 💖 when local address validation is used within a group of networks, it's assured that their networks don't send spoofed packets. but other networks might still do it 😭 with the scheme above, that capability is eliminated. if someone outside the alliance spoofs a packet using a source address from someone inside the alliance, the alliance members refuse to accept that packet 🙅♀️
+-----+
.-----------------+ REG |-----------------.
| +-----+ |
| |
,-----+-------- ,------+-------
,' `| `. ,' ` | `.
/ | \ / | \
/ | \ / | \
; +--'--+ +----+ +----+ +-----+ ;
| | ASC +------+ASBR| |ASBR+-----+ ASC | |
: +--.--+ +----+` +----+ +--+--+ :
\ |__________________________________________| /
\ / \ /
`. ,' `. ,'
'-------------' '-------------'
AS-1 AS-2
Key: REG - Registration Server
ASC - AS Control Server
ASBR - AS Border Router
Figure 4: Inter-AS (Non-Neighboring AS) Solutionthere are three major parts to this system 🌷 the Registration Server (REG), the AS Control Server (ASC), and the AS Border Router (ASBR) 🍓
the Registration Server is the "center" of the trust alliance (TA) 👑 it keeps a member list for the TA, and it does two big jobs:
- it processes requests from the AS Control Server, so it can get the member list for the TA.
- it tells each AS Control Server whenever the member list changes.
every AS using this method has an AS Control Server 💜 the AS Control Server has three main jobs:
- it talks to the Registration Server to get the up-to-date member list of the TA.
- it talks to the AS Control Servers in other member ASes in the TA, to swap updates about prefix ownership and to swap authentication tags 🫶
- it talks to all the AS Border Routers of its local AS, so it can configure their processing component.
the AS Border Router is the one actually adding the authentication tag to packets at the sending AS, and verifying and removing the tag at the destination AS 🔥
and here's the smart bit: to take some pressure off the REG, most of the control traffic happens between ASCs 🧠
the authentication tag has to change periodically 🔄 yes, the overhead of maintaining and exchanging tags between AS pairs is O(N) from the point of view of one AS, not O(N^2), but the traffic and processing overhead still go up as the number of ASes goes up 😭 so this solution uses an automatic tag refresh mechanism. each peer runs the same algorithm to automatically generate an authentication tag sequence, so the tag in packets can change automatically and very frequently ✨ to boost security, a seed is used for the algorithm so the tag sequence is robust against guessing. that means the peers only need to negotiate and change the seed at a very low frequency 💅 this cuts down the overhead of constantly negotiating new tags while still keeping security at an acceptable level ✨
since the tag lives in an IPv6 hop-by-hop extension header, the MTU issues should be considered 📏 there are currently two solutions to this. neither one is perfect, but both are feasible 🌸 option one: set the MTU at the ASBR to 1280 bytes, which is the minimum MTU for IPv6. then there should be no ICMP "Packet Too Big" message coming back from the downstream gateways. the downside is that it doesn't make good use of the available MTU 🙈 option two: let the ASBR catch all incoming ICMP "Packet Too Big" messages and decrease the value in the MTU field before forwarding them into the AS. the upside is that this makes good use of the available MTU ✨ but processing ICMP packets at the ASBR like this may create a target for a denial-of-service (DoS) attack 💀
because the tag gets validated at the border router of the destination AS, not at the destination host, the destination options header is not chosen to carry the tag 🎀
tag management is a critical issue 🚨 this work focused on two points: tag negotiation and tag refresh. tag negotiation happens between the ASCs of a pair of ASes in the SAVA AS Alliance. considering synchronization and the incentive to enable SAVA, receiver-driven tag negotiation is suggested 🦋 it gives more decision power to the receiver AS instead of the sender AS, so the receiver AS can decide the tag management policies. packets tagged with old authentication tags should not be allowed indefinitely. instead, once a new tag has been negotiated, the old tag should be set to invalid after a period of time. the length of that period is a parameter that controls how long the old tag stays valid after the new one is assigned. in the experiment, they used five seconds ⏱️
the trust alliance is meant to be established dynamically (members can join and quit), but in this testbed they had to confirm the initial trust among alliance members off-line 🧚
3. SAVA Testbed ✨
3.1. CNGI-CERNET2 🌐
the SAVA prototypes were implemented and tested on CNGI-CERNET2 💖 it's one of the China Next Generation Internet (CNGI) backbones, operated by the China Education and Research Network (CERNET) 🇨🇳 CNGI-CERNET2 connects 25 core nodes spread across 20 cities in China, at speeds of 2.5-10 Gb/s 🚀 the CNGI-CERNET2 backbones are IPv6-only networks, not a mixed IPv4/IPv6 infrastructure 👑 only some Customer Premises Networks (CPNs) are dual-stacked 🌸 the CNGI-CERNET2 backbones, CNGI-CERNET2 CPNs, and CNGI-6IX all have globally unique AS numbers, so a multi-AS testbed environment is provided 🌈
3.2. SAVA Testbed on CNGI-CERNET2 Infrastructure 🌐
okay so the big dream is for the SAVA testbed to live directly on the CNGI-CERNET2 backbone one day 💖 but for now it's spread across 12 universities that are connected to CNGI-CERNET2 🎓. why? two reasons, bestie. first, some of the algorithms need to run inside the testbed routers themselves, and so far none of the commercial routers that make up the CNGI-CERNET2 backbone have them 🙈. second, CNGI-CERNET2 is a live, operational backbone, so any new protocols and networking techniques have to be tested in a non-disruptive way 🫶. nobody wants to break the internet for their science project, periodt 💅
__
,' \ _,...._
,' \____---------------+ ,'Beijing`.
/ \ | Inter-AS SAV |-----| Univ |
+---------------+ | | +---------------+ `-._____,'
| Inter-AS SAV +-----| |
+------.--------+ | CNGI- | _,...._
| | CERNET2 |__---------------+ ,Northeast`.
| | | |Inter-AS SAV |-----| Univ |
Tsinghua|University | Backbone| +---------------+ `-._____,'
,,-|-._ | |
,' | `. | |
,'+---------+\ | |
| |Intra-AS | | | | ...
| | SAV | | | |
| +---------+ | | |
| | | | | _,...._
| +---------+ | | |__---------------+ ,Chongqing`.
| | Access | | | | |Inter-AS SAV |-----|Univ |
| | Network | | | | +---------------+ `-._____,'
| | SAV | | | |
\ +---------+.' \ .'
\ ,' \ |
`. ,' \ /
``---' -_,'
Key: SAV - Source Address Validation
Figure 5: CNGI-CERNET2 SAVA Testbedanyway, the testbed is totally capable of functional testing for every part of SAVA ✨ that covers checking IPv6 source addresses in the access network, in packets going from the access network out to an IPv6 service provider, in packets moving around inside one service provider's network, in packets flowing between neighboring service providers, and in packets sent between service providers that are separated by a transit network in the middle 🦋
the testbed is spread across 12 universities connected to CNGI-CERNET2 🌸
each university installation hooks into the CNGI-CERNET2 backbone through a set of inter-AS Source Address Validation prototype equipment, plus traffic monitoring equipment that shows the test results 📊
each university deployed one AS 🏫. six of them went all in and deployed every part of the solution, so they're fully-featured 👑 and validation at the inter-AS, intra-AS, and access network levels can all be tested. on top of that, a whole suite of applications that could be hit by spoofing attacks, or that can be twisted into carrying out spoofing attacks, got installed on a bunch of servers 🧚 and two solutions for the access network were deployed too. the chaos is immaculate 😭
4. Test Experience and Results 🎀
the solutions from section 2 got implemented on the testbed from section 3, and testing of all solutions was successful 🥳 the details are in the sections below ✨
4.1. Test Scenarios 🧪
for each test scenario, we tested a ton of cases 💜 let's take the Inter-AS (non-neighboring AS) SAVA solution test as an example. we sorted the test cases into three classes: normal class, dynamic class, and anti-spoofing class.
- for the normal class, there are three cases: Adding authentication tag Test, Removing authentication tag Test, and Forwarding packets with valid source address.
- for the dynamic class, there are four cases: Updating the authentication tag between ASes, The protection for a newly joined member AS, Adding address space, and Deleting address space.
- for the anti-spoofing class, there is one case: Filtering of packets with forged IP addresses.
as shown in Figure 5, our SAVA testbed has a "multiple-fence" design 🏰 if source address validation is deployed in the access network, we get host granularity validation 🎯. if it's deployed at the intra-AS level, we can guarantee that packets sent from that point have a correct IP prefix 💅. and if it's deployed at the inter-AS level, we can guarantee that packets sent from that point are from the correct AS 🔥
4.2. Test Results 📈
- the test results match the expected ones 🙌 for an AS with fully-featured SAVA deployment, validation at the inter-AS, intra-AS, and access network levels means packets that don't hold an authenticated source address will not be forwarded in the network. as a result, it is not possible to launch network attacks with spoofed source addresses 🛡️ on top of that, the traffic in the network can be traced back accurately 🔍 main character energy.
- for the Inter-AS (non-neighboring AS) SAVA solution, during the authentication tag update period, the old and the new authentication tags are both valid for source address validation. so, there is no packet loss 🌊✨
- for the Inter-AS (non-neighboring AS) SAVA solution, the validation function is implemented in software on a device running Linux 🐧, which simulates the source address validation functions of a router interface. it's a layer-2 device, because it needs to be transparent to the router interface 🦋. when the devices were connected directly, normal line-rate forwarding was achieved 🚀. when they were connected with routers from another vendor, only a very limited forwarding speed was achieved 🥲. the reason? the authentication tags are added on the IPv6 hop-by-hop option header, and many current routers can handle hop-by-hop options only at a limited rate 😩
5. Limitations and Issues 🚧
okay, real talk time 🫶 there are several issues, both within this overall problem area and with the particular approach taken in the experiment.
5.1. General Issues 🌍
there's a long-standing debate about whether the lack of universal deployment of source address validation is a technical issue that needs a technical solution, or whether just deploying the existing tools more (like RFC 2827) would be a more cost effective way to improve things 🤔. further deployment of this tool has been slow, though 😔. some of the solutions prototyped in this experiment let a group of network operators have extra protection for their networks while everyone else waits for universal deployment of simpler tools across the rest of the Internet 🛡️. that means they can stop spoofing attacks that the simple tools alone couldn't prevent, even if those simple tools are already deployed within the group 💖
similarly, since a big chunk of current denial-of-service attacks can be launched using legitimate IP addresses belonging to botnet clients, even universal deployment of better source address validation techniques wouldn't be able to prevent these attacks 💀. however, tracing these attacks would be easier, given that there would be more reliance on the validity of source addresses 🔍
there's also a question about the optimal placement of source address validation checks 📍. the simplest model is placing the checks on the border of a network. these RFC 2827-style checks are more widely deployed than full checks ensuring that all addresses within the network are correct 🧱. it can be argued that coarse granularity checks like these are enough, because they at least make it possible to find the responsible network administrators 🕵️♀️. however, depending on the type of network, those administrators may or may not find it easy to track down the specific offending machines or users 🙈. it is obviously required that administrators have a way to trace offending equipment or users, even if the network doesn't block spoofed packets in real time 🫶
new technology for address validation would also face a number of deployment barriers 🚧. for instance, all current technology can be applied locally and independently. a system that requires global operation (such as the Inter-AS validation mechanism) would need significant coordination, deployment synchronization, configuration, key setup, and other stuff, given the number of ASes 😵💫
similarly, deploying host-based access network address validation mechanisms requires host changes, and can generally only be done when the network owners control all hosts 🖥️. even then, the changing availability of the host across all types of products and platforms would likely prevent universal deployment, even within a single network 🥀
there may also be significant costs involved in some of these solutions 💸. for instance, in an environment where access network authentication is normally not required, employing authentication-based access network address validation would mean deploying equipment capable of that authentication, plus credential distribution for all devices. that kind of undertaking is typically only started after careful evaluation of the costs and benefits involved 🧾
finally, all the presented solutions have issues in situations that go beyond a simple model of a host connecting to a network via the same single interface at all times 🌀. multihoming, failover, and some forms of mobility or wireless solutions may collide with the requirements of source address validation 📶. in general, dynamic changes to the attachment of hosts and to the topology of the routing infrastructure are something that would have to be handled in a production environment 🏭
5.2. Security Issues 🔐
the security vs. scalability trade-off of the authentication tags in the Inter-AS (non-neighboring AS) SAVA solution is a seriously difficult one 😭. some analysis of how hard it is to guess the authentication tag between two AS members was discussed in [Brem05]. it is relatively difficult, even when using a random number as the "authentication tag" 🎲. the difficulty of guessing can be increased by making the authentication tag longer 📏
⚠️ in any case, the random number approach is definitely vulnerable to attackers who are on the path between the two ASes. this is a big red flag, bestie 🚩
on the other hand, using an actual cryptographic hash in the packets will cause a significant increase in the effort needed to forward a packet 🐌. in general, adding the option and calculating the authentication tag both eat up valuable resources on the forwarding path 🍽️. this resource usage comes on top of everything else modern routers need to do at ever-increasing line speeds 🏎️. it is far from clear that the costs are worth the benefits 🤷♀️💅
5.3. Protocol Details 💅
Okay so in the current CNGI-CERNET2 SAVA testbed, the 128-bit authentication tag rides along inside an IPv6 hop-by-hop option header 🦋 Bigger tags mean bigger packets, and that's honestly fine if your network admin feels they need the extra protection. Those bigger sizes can cause an MTU issue, but we found a way to fix it in the testbed ✨
Here's the tea 🍵 Because it's a hop-by-hop option, every router in the path has to look at it. In theory that's no big deal, but the test results showed that a lot of current routers handle hop-by-hop options way slower than normal traffic. Lowkey a glow-down for throughput 💀
The Inter-AS (neighboring AS) SAVA solution is built on the AS relationship, so it might not keep up with route changes super fast, and it could cause false positives 🙈 The good news is that CNGI-CERNET2 is a pretty stable network, so this method slays in the testbed 💖 We'll keep studying how false positives affect an unstable network, because that's the next chapter 📚
The access network address validation solution is just one option out of many 🌈 The best choice depends heavily on the link technology and the network architecture. Source address validation on point-to-point links is easy, and implementations have supported it for years, so that's giving easy mode 💅 Validation on shared networks is more of a struggle, but it's becoming more important because Ethernet is now used across administrative boundaries (like in DSL). Anyway, the prototype has a bunch of limitations, including the choice to use a brand-new address configuration protocol. For a production environment, we'd need a solution that works with all IPv6 address assignment mechanisms 🫶
6. Conclusion 🎀
Okay, time for the big takeaways from the experiment 👑
First, the experiment proves that a prototype can be built that's deployable on loosely-coupled domains of test networks, at a limited scale, using a "multiple-fence" design for source address validation 🧚 The solution lets you pick different validation granularities, and it also lets different providers use different solutions. The components are coupled loosely enough that you can swap one out for another. Iconic flexibility 🦋
Incremental deployment was another design principle in the experiment ✨ The tests showed that people still get benefits even when deployment isn't complete. So providers have a real reason to be early adopters 💜
The experiment also gave us a proof of concept for four mechanisms: switch-based local subnet validation, network authentication based validation, filter-based Inter-AS validation, and authentication tag-based Inter-AS validation 🌸 To make these work, the client host and network equipment need to be modified, and some new servers need to be deployed 🛠️
Nevertheless, as we talked about in the previous section, the prototype designs and the overall source address validation space still have a number of limitations, issues, and open questions 😭
We really hope some of these experiences help vendors and the Internet standards community with this work 🫶 Future work in this space should try to answer some of the issues raised in Section 5. Some of the key issues going forward include:
- Scalability questions and per-packet operations.
- Protocol design issues, such as integration to existing address allocation mechanisms, use of hop-by-hop headers, etc.
- Cost vs. benefit questions. These may be ultimately answered only by actually employing some of these technologies in production networks.
- Trust establishment issue and study of false positives.
- Deployability considerations, e.g. modifiability of switches, hosts, etc.
7. Security Considerations 🔐
The purpose of this document is to report experimental results 🧪 Some security considerations of the testbed's solution mechanisms are mentioned in the document, but they aren't the main problem this document is here to describe. So no drama, just context 💅
8. Acknowledgements 💖
This experiment was conducted among 12 universities, namely Tsinghua University, Beijing University, Beijing University of Post and Telecommunications, Shanghai Jiaotong University, Huazhong University of Science and Technology in Wuhan, Southeast University in Nanjing, South China University of Technology in Guangzhou, Northeast University in Shenyang, Xi'an Jiaotong University, Shandong University in Jinan, University of Electronic Science and Technology of China in Chengdu, and Chongqing University. The authors want to thank everyone involved from these universities 🌈
The authors also want to thank Jari Arkko, Lixia Zhang, and Pekka Savola for their detailed review comments on this document 🙌 And a huge thank you to Paul Ferguson and Ron Bonica for their valuable advice on the solution development and the testbed implementation ⭐
9. References 📚
9.1. Normative References
[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.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.9.2. Informative References
[Brem05] Bremler-Barr, A. and H. Levy, "Spoofing Prevention
Method", INFOCOM 2005.
[Li02] Li,, J., Mirkovic, J., Wang, M., Reiher, P., and L.
Zhang, "SAVE: Source Address Validity Enforcement
Protocol", INFOCOM 2002.
[Park01] Park, K. and H. Lee, "On the effectiveness of route-based
packet filtering for distributed DoS attack prevention in
power-law internets", SIGCOMM 2001.
[Snoe01] Snoeren, A., Partridge, C., Sanchez, L., and C. Jones, "A
Hash-based IP traceback", SIGCOMM 2001.
[Wu07] Wu, J., Ren, G., and X. Li, "Source Address Validation:
Architecture and Protocol Design", ICNP 2007.
[XBW07] Xie, L., Bi, J., and J. Wu, "An Authentication based
Source Address Spoofing Prevention Method Deployed in IPv6
Edge Network", ICCS 2007.Authors' Addresses 🦋
Jianping Wu
Tsinghua University
Computer Science, Tsinghua University
Beijing 100084
China
EMail: jianping@cernet.edu.cn
Jun Bi
Tsinghua University
Network Research Center, Tsinghua University
Beijing 100084
China
EMail: junbi@cernet.edu.cn
Xing Li
Tsinghua University
Electronic Engineering, Tsinghua University
Beijing 100084
China
EMail: xing@cernet.edu.cn
Gang Ren
Tsinghua University
Computer Science, Tsinghua University
Beijing 100084
China
EMail: rg03@mails.tsinghua.edu.cn
Ke Xu
Tsinghua University
Computer Science, Tsinghua University
Beijing 100084
China
EMail: xuke@csnet1.cs.tsinghua.edu.cn
Mark I. Williams
Juniper Networks
Suite 1508, W3 Tower, Oriental Plaza, 1 East Chang'An Ave
Dong Cheng District, Beijing 100738
China
EMail: miw@juniper.netFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008) 💜
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧾
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't 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, 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 💌
📦 where this page comes from
- ietf: rfc5210 2008-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms