IPv6 Source Address Validation and IETF Efforts

Jun Bi

CERNET/Tsinghua University

APAN 26

August, 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- 2007 Arbor Worldwide Infrastructure Security Report

Related Work• IETF BCP 38 filtering (needs to be fully deployed), i

f it were universally applied would solve the problem. Unfortunately this is not the case– about ¼ of the Internet at least allows spoofed source ad

dresses 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

Transit AS

Access Network

ASAS

Access Network

AS

Inter-AS

Intra-AS

Interface IDLevel Granularity

IP Prifix LevelGranularity

AS LevelGranularity

Access Network

IP Prefix LevelGranularity

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):

Regi strat i on Server

AS Control Server AS Control Server

Edge Router Edge Router

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

A End-to-end lightweight Signature based Solution for Inter-AS SAVA

Global IPv6 Network

AS-1

AS-2 AS-3

AS-4

Add signaturecheck signature, validRemove signature

Ingress filtering

Check signature, invalid

Unsigned Flow

Signed Flow

攻击者2

AS100 AS200

AS300

OSPFOSPF

OSPF

客户机

Web/媒体服务器

CERNET 2

攻击者3

攻击者1

Email

DNS

SIP

BBS EmailSIP SIP Email

SAVA Testbed: Test Result (1)

Before spoofing attack

攻击者2

AS100 AS200

AS300

OSPFOSPF

OSPF

客户机

Web/媒体服务器

CERNET 2

攻击者3

攻击者1

Email

DNS

SIP

BBS EmailSIP SIP Email

SAVA Testbed: Test Result (2)

After spoofing attack

攻击者2

AS100 AS200

AS300

OSPFOSPF

OSPF

客户机

Web/媒体服务器

CERNET 2

攻击者3

攻击者1

Email

DNS

SIP

BBS EmailSIP SIP Email

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

SAVA

用户接入网

SAVA

SAVA

SAVA

SAVA

SAVA

SAVASAVA

SAVA

SAVA

IETF Efforts• IETF 66 (Montreal, July 2006), SAVA Side Meeting with IAB/IE

SG • 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 A

rea 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

Why we need host-granularity anti-spoofing

Edge Network

Other Networks

Master

Slave1

Slave3Victim

Slave2

Reflector1 Reflector2 Reflector3

Request:src= victim

dst=reflector

Reply:src= reflector

dst=victim

Server

IPv6 source address assigned

Access request

Binding in switch

Access network

2001:250:f001:f002:210:5cff:fec7:1204

00-02-3F-B6-DC-9A

2001:250:f001:f002:210:5cff:fec7:1204

2001:250:f001:f002:210:5cff:fec7:1204

00-02-3F-B6-DC-9A+ +{ Port 2 }

Access accepted

2001:250:f001:f002:210:5cff:fec7:1204

00-02-3F-B6-DC-9A+ +{ Port 2 }

}2001:250:f001:f002:210:5cff:fec7:1204

00-02-3F-B6-DC-9A+ +{ Port 2

＝

Match ?

Assigned address2001:250:f001:f002:210:5cff:fec7:1204Spoof address

2001:250:f001:f002:210:5cff:fec7:1203

Match ?

2001:250:f001:f002:210:5cff:fec7:1204

00-02-3F-B6-DC-9A+ +{ Port 2 }

2001:250:f001:f002:210:5cff:fec7:1204

00-02-3F-B6-DC-9A+ +{ Port 2 }

≠Access denied

Switch port based Solution

Protocols

Client SwitchAuthentication And Address

Allocation Sever

2. EAP-Response / Identity

4 .Radius Access Request

7. Radius Access Accept(With Allocated IP Address)

9. EAP-Success(With Allocated IP Address)

10. Valid Source AddressPermit

11. Spoof Source AddressNot Permit

5. Authentication

6. Address Allocation

3.Register Client MAC Address & Port Num

8. Set the Binding Rule (IP Address, MAC Address, Port)

1. EAP-Request / Identity

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 Irequire 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 appoin

ted 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 packetwith source addressset to the address prepared in phase 1• The CGA option and RSA signature option arethe 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.

– SAC/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 has been used to apply address/prefix from DHCP server/router. [See next page]

Address Allocation in DHCP Case

Source address set to theCGA 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 choice 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)

SAVA Deployment Plan• Phase 1:

– Prototypes implemented and 12 SAVA test ASes deployed in CNGI-CERNET2

– Supported by “863” High-tech project and CNGI project

• Phase 2: – Collaborating with vendors to implement SAVA in route

r/switch products (Cisco, Juniper, Huawei, and Bitway showed interests).

– Deploy 100 SAVA campus networks in CNGI-CERNET2 and to protect 1 Million users with source address spoofing prevention methods

– Collaborate with China Telecom, China Mobile, etc. to deploy SAVA on the whole CNGI network in the future.

– IETF efforts: solutions revision/RFC standardization.– Supported by MOST 11th 5-year Plan Project

Thank You!