A Source Address Validation Architecture (SAVA) and IETF SAVI Working Group

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

2. 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

3. 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)

4. Some Figures- 2007 Arbor Worldwide Infrastructure Security Report

5. 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

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

7. SAVA Architecture in CNGI-CERNET2 IP Prefix Level Granularity

8. 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)

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

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

11. SAVA Testbed: Test Result (1) Before spoofing attack

12. SAVA Testbed: Test Result (2) After spoofing attack

13. SAVA Testbed: Test Result (3) Enable SAVA

14. Test-bed in CERNET2/Tsinghua Univ.

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

16. 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: https://www.ietf.org/mailman/listinfo/savi

17. 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

18. Why we need host-granularity anti-spoofing

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

20. Protocols

21. 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

22. 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 Identifierand 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

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

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

25. 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

26. 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.

27. 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]

28. 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]

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

30. 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”.

31. 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)

32. Thank You!Q & A