A Source Address Validation Architecture (SAVA) and IETF SAVI Working Group Jun Bi Tsinghua University/CERNET Oct 20, 2008

Outline Background and Requirements A Source Address Validation Architecture (SAVA) and CNGI-CERNET2 SAVA Testbed – RFC5210: J Wu, J Bi, X Li, et.al. IETF SAVI (Source Address Validation Improvements) WG and Proposed Solutions

What Is the problem Current situation in IPv4 and IPv6 is that: –destination address based packet forwarding –In the forwarding process, the source IP address is not checked in most cases. –Easy to spoof the source address of the IP packet. Packets with spoofed source addresses are unwanted. –Security (Attacks such as DNS reflection) –Management (Administration: hard to trace back, measurement) –Accounting (source address based accounting)

Some Figures Arbor Worldwide Infrastructure Security Report

Related Work IETF BCP 38 filtering (needs to be fully deployed), if it were universally applied would solve the problem. Unfortunately this is not the case –about ¼ of the Internet at least allows spoofed source addresses in packets (MIT Spoofer Project) –BCP 38 deployment ratio is less than 50% (Arbort report) Cryptographic based methods –Cost/feasibility Traceback based methods –Reactive, not proactive

SAVA Design Principles 1.Hierarchical Architecture (Multi-fence solutions) 2.Solutions for IPv6 first (feasible way to deploy) 3.Proactive protection 4.Incrementally Deployable (Incomplete deployment still be beneficial) 5.Provide incentive for deployment (The source address space of a network that deployed SAVA can not be spoofed by others) 6.Performance, Cost and Scalability

SAVA Architecture in CNGI-CERNET2 IP Prefix Level Granularity

Current SAVA Solutions in CNGI-CERNET2 Inter-AS (early stage): lightweight signature between the source AS and the destination AS (End-to-end) Inter-AS (neighboring ASes): AS relationship based method deployed in the neighboring AS boarder routers Intra-AS: deploy Ingress filtering on all edge routers in an AS (the ingress filtering relies on fully deployment. it’s not feasible to fully deploy in the whole Internet, but it’s feasible to deploy in a single AS). Access Network (First-Hop, Local Subnet)

A End-to-end lightweight signature based solution for Inter-AS SAVA

A End-to-end lightweight Signature based Solution for Inter-AS SAVA Add signature check signature, valid Remove signature Ingress filtering Check signature, invalid Unsigned Flow Signed Flow

SAVA Testbed: Test Result (1) Before spoofing attack

SAVA Testbed: Test Result (2) After spoofing attack

SAVA Testbed: Test Result (3) Enable SAVA

Test-bed in CERNET2/Tsinghua Univ.

SAVA Deployment in CNGI-CERNET2: Prototype implemented and 12 SAVA test AS deployed 用户接入网 SAVA 用户接入网 SAVA

IETF Efforts IETF 66 (Montreal, July 2006), SAVA Side Meeting with IAB/IESG IETF 67 (San Diego, Nov 2006), Internet Area Open Meeting IETF 68 (Prague, March 2007), first BoF Discussion IETF 69 (Chicago, July 2007), RFC drafts proposed, Internet Area Open Meeting and SAVA Side Meeting with IESG to prepare the 2nd BoF IETF 70 (Vancouver, Dec. 2007), BoF for SAVI Working Group (Source Address Validation Improvements) IETF 71 (Philadelphia, March 2008), discuss/revise WG charter RFC 5210 and SAVI WG were approved by IESG in May 2008 IETF 72 (Dublin, July 2008), the first SAVI WG meeting To Subscribe:

IETF SAVI WG To resolve the source address validation in the access network Co-chairs: –Christian Vogt –Bill Fenner Technical Advisor: –Jianping Wu Secretary –Jun Bi

Why we need host-granularity anti-spoofing

IPv6 source address assigned Access request Binding in switch Access network 2001:250:f001:f002: 210:5cff:fec7: F-B6-DC-9A 2001:250:f001:f002: 210:5cff:fec7: F-B6-DC-9A ++{ Port 2 } Access accepted 2001:250:f001:f002: 210:5cff:fec7: F-B6-DC-9A ++{ Port 2 } } 2001:250:f001:f002: 210:5cff:fec7: F-B6-DC-9A ++{ Port 2 ＝ Match ? Assigned address 2001:250:f001:f002: 210:5cff:fec7:1204 Spoof address 2001:250:f001:f002: 210:5cff:fec7:1203 Match ? 2001:250:f001:f002: 210:5cff:fec7: F-B6-DC-9A ++{ Port 2 } 2001:250:f001:f002: 210:5cff:fec7: F-B6-DC-9A ++{ Port 2 } ≠ Access denied Switch port based Solution

Protocols

Special Problems in IPv6 Various Address Allocation Methods –Stateless Auto-configuration –DHCPv6 –Manual Configuration/Static –Cryptographically (CGA) –Private Multiple addresses are assigned to an interface

CGA based Solution Phase 1: Address Authorization –Filtering based on the knowledge of address assignment (to adapt all address allocation ways) –Host Identifier (CGA Identifier) without PKI –Binding Host Identifier and address at the first Layer-3 hop –Secure Shared Secret Exchange (Signature seed used in Authentication phase) Phase 2: Address Authentication –Light-weight signature generation –Light-weight signature adding and removal

Overview of Procedure Phase1: Address Authorization (5 steps) (4) Check whether identifier H can use the required address A (3) I’m H and I require to use address A (5) Return a “signature seed” for future authentication (2) An identifier is used to show the applicant is H (1) Prepare an address A

Overview of Procedure Phase2: Address Authentication Add Signature Check Signature and Remove it Generate Signature based on “signature seed”

Phase1: Address Authorization Step 1: Address Preparation –The Node gets an address through the appointed address assignment mechanism Host in IPv4: Manual Configuration, DHCP Host in IPv6: DHCP, Stateless Autoconfiguration, Manual Configuration, Cryptographically Generated Address, Privacy

Address Authorization Step 2: Identifier Generation –Node generates a secure identifier For anonymity address owner (DHCP,SCA,CGA,Privacy), identifier = hash(Public Key) [Described in CGA] For any address allocation mechanism involving manual configuration, identifier = hash(Public Key + Share Secret ). The Share Secret is a bit string allocated to the node with the static address by network administrator.

Address Authorization Step 3: Address Authorization Request –Nodes send a request packet to the first layer 3 hop (gateway/router) An ICMP packet with source address set to the address prepared in phase 1 The CGA option and RSA signature option are the same as described in [SEND]

Address Authorization Step 4: Gateway Authorizing Address –Gateway checks whether the request node has the right to use the address. The knowledge is based on address allocation. –Manual Configuration: Re-compute the identifier using the shared secret of the address owner. –SCA/Privacy/CGA: The address has not been registered by another node. In CGA case, the request address must be a correct CGA address computed on the public key. –DHCP: The identifier in the request packet must be the one which was used to apply address/prefix from DHCP server/router. [See next page]

Address Allocation in DHCP Case Source address set to the CGA identifier Record the CGA identifier Record the address allocated. Bind the identifier and the address. DHCP Solicitation

Address Authorization Step 5: Signature Seed Assignment –Gateway returns a bit string named “signature seed” to the applicant, encrypted by the public key in the request packet. –Node decrypts the “signature seed”.

Phase 2: Address Authentication Signature Generation (All based on the shared secret “signature seed”) –HMAC –Pseudo Random Number (Preference) Signature sequence, hard to guess and replay Using the sliding window to handle the packet re-order (not a big deal in local subnet) Signature Adding (3 choices to implement) –IPSEC Authentication Header –A new option header (e.g. Hop-by-hop) –Address Rewrite (The signature is used as local address, the router rewrite with the authorized address for out world, to save the cost of memory copy and locating header) Signature Verification (matching the random number)

Thank You! Q & A