Transcript 1100-1130 Jun Bi

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),
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.
2.
3.
4.
Hierarchical Architecture (Multi-fence solutions)
Solutions for IPv6 first (feasible way to deploy)
Proactive protection
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
AS Level
Granularity
Transit AS
Inter-AS
AS
AS
IP Prefix
Prifix Level
IP
Level
Granularity
Granularity
Intra-AS
Access Network
Interface ID
Access Network Level Granularity
Access Network
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
Registration Server
Edge Router
AS Control Server
Edge Router
AS Control Server
A End-to-end lightweight Signature
based Solution for Inter-AS SAVA
AS-4
AS-1
Global IPv6
Network
AS-2
Unsigned Flow
Signed Flow
Add signature
Ingress filtering
Check
signature,
check
signature,
valid invalid
Remove
signature
AS-3
SAVA Testbed: Test Result (1)
客户机
Email
攻击者3
AS300
OSPF
DNS
CERNET 2
SIP
AS200
AS100
OSPF
OSPF
SIP
BBS
Email
攻击者2
Web/媒体服务器
攻击者1
SIP
Email
Before spoofing
attack
SAVA Testbed: Test Result (2)
客户机
Email
攻击者3
AS300
OSPF
DNS
CERNET 2
SIP
AS200
AS100
OSPF
OSPF
SIP
BBS
Email
攻击者2
Web/媒体服务器
攻击者1
SIP
Email
After spoofing
attack
SAVA Testbed: Test Result (3)
客户机
Email
攻击者3
AS300
OSPF
DNS
CERNET 2
SIP
AS200
AS100
OSPF
OSPF
SIP
BBS
Email
攻击者2
Web/媒体服务器
攻击者1
SIP
Email
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
SAVA
SAVA
用户接入网
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: https://www.ietf.org/mailman/listinfo/savi
Why we need host-granularity
anti-spoofing
Reflector1
Reflector2
Reflector3
Other Networks
Request:
src= victim
dst=reflector
Slave2
Reply:
src= reflector
dst=victim
Slave1
Slave3
Master
Victim
Edge Network
Switch port based Solution
Server
Access request
2001:250:f001:f002:
210:5cff:fec7:1204
IPv6 source
address assigned
Access accepted
Binding in switch
{
00-02-3F-B6-DC-9A
{{
2001:250:f001:f002:
210:5cff:fec7:1204
2001:250:f001:f002:
2001:250:f001:f002:
210:5cff:fec7:1204
210:5cff:fec7:1204
Match ?
Match
+ 00-02-3F-B6-DC-9A
?
++
00-02-3F-B6-DC-9A
00-02-3F-B6-DC-9A
}
Port 2
++
Port 22
Port
}}
++
Port 22
Port
}}
＝
≠
Assigned
2001:250:f001:f002:
address
Access denied
2001:250:f001:f002:
210:5cff:fec7:1204
2001:250:f001:f002:
2001:250:f001:f002:
00-02-3F-B6-DC-9A
Spoof
address
{
210:5cff:fec7:1204
{
++ 00-02-3F-B6-DC-9A
210:5cff:fec7:1204
210:5cff:fec7:1204
2001:250:f001:f002:
210:5cff:fec7:1203
+
Access network
Protocols
Client
Authentication
And Address
Allocation Sever
Switch
1. EAP-Request / Identity
2. EAP-Response / Identity
3.Register Client MAC
Address & Port Num
4 .Radius Access Request
5. Authentication
6. Address
Allocation
7. Radius Access Accept
(With Allocated IP Address)
8. Set the Binding Rule (IP
Address, MAC Address, Port)
9. EAP-Success
(With Allocated IP Address)
10. Valid Source Address
Permit
11. Spoof Source Address
Not Permit
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
(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
Overview of Procedure
• Phase2: Address Authentication
Check Signature and
Remove it
Add Signature
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.
– 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
Record the CGA
identifier
Record the
address allocated.
Bind the identifier
and the address.
Source address
set to the
CGA identifier
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
router/switch products (Cisco, Juniper, Huawei, and
Bitway showed interests).
– Deploy 100 SAVA campus networks in CNGICERNET2 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!