SAVA Introduction by 8yyVE4

VIEWS: 0 PAGES: 32

									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. 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
                                       AS Level
                                      Granularity
            Transit AS



            Inter-AS
                                     IP Prifix Level
                                     IP Prefix Level
                                       Granularity
                                       Granularity
      AS                    AS


             Intra-AS

                                    Interface ID
Access Network     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      Edge Router
AS Control Server                          AS Control Server
    A End-to-end lightweight Signature
    based Solution for Inter-AS SAVA
          AS-4                               AS-1



                                                        Global IPv6
                                                         Network




                                                        Check signature,
                                                    check signature, valid invalid
                                                       Remove signature
                AS-2   Add signature                      AS-3
                         Ingress filtering




Unsigned Flow

 Signed Flow
      SAVA Testbed: Test Result (1)
                                                                客户机

                                                                Email

                                                                攻击者3
                   AS300      OSPF

                                                                DNS

CERNET 2                                                        SIP




           AS100                              AS200




                                      OSPF
                    OSPF




                                                                                Before spoofing
                                                                        Email
                               攻击者2                      攻击者1
                                                                                    attack
SIP         BBS       Email                  Web/媒体服务器          SIP
      SAVA Testbed: Test Result (2)
                                                                客户机

                                                                Email

                                                                攻击者3
                   AS300      OSPF

                                                                DNS

CERNET 2                                                        SIP




           AS100                              AS200




                                      OSPF
                    OSPF




                               攻击者2                      攻击者1           Email
                                                                                After spoofing
SIP         BBS       Email                  Web/媒体服务器          SIP




                                                                                    attack
      SAVA Testbed: Test Result (3)
                                                                客户机

                                                                Email

                                                                攻击者3
                   AS300      OSPF

                                                                DNS

CERNET 2                                                        SIP




           AS100                              AS200




                                      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
    Slave1                                                             dst=victim

                                                             Victim
                                       Slave3




             Master                             Edge Network
   Switch port based Solution
                                                                                  Server




      Access request                                        2001:250:f001:f002:     IPv6 source
                                                             210:5cff:fec7:1204   address assigned
                                                        Access accepted


                                                        Binding in switch

                                            2001:250:f001:f002:   Match ?
00-02-3F-B6-DC-9A                     {      210:5cff:fec7:1204
                                                                   + 00-02-3F-B6-DC-9A
                                                                  Match ?                      +    Port 2       }
                                          2001:250:f001:f002:
                                          2001:250:f001:f002:
                                  {
                                  {        210:5cff:fec7:1204
                                                                  +
                                                                  +   00-02-3F-B6-DC-9A
                                                                      00-02-3F-B6-DC-9A    +
                                                                                           +       Port 2
                                                                                                   Port 2    }
                                                                                                             }
                                           210:5cff:fec7:1204
                                                                  ≠




                                                                       =
                           2001:250:f001:f002:
                     Assigned address
                    2001:250:f001:f002:
                            210:5cff:fec7:1204     Access denied
                                          2001:250:f001:f002:
                                      { 2001:250:f001:f002: + 00-02-3F-B6-DC-9A
                            Spoof address
                     210:5cff:fec7:1204
                                      {    210:5cff:fec7:1204
                                                              + 00-02-3F-B6-DC-9A          +
                                                                                           +       Port 2
                                                                                                   Port 2    }
                                                                                                             }
                                          210:5cff:fec7:1204
                         2001:250:f001:f002:
                          210:5cff:fec7:1203



             Access network
                                       Protocols

                                                                                       Authentication
Client                                    Switch                                        And Address
                                                                                       Allocation Sever

          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        (3) I’m H and I
                   address A      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




                                                   Source address
   Record the
                                                   set to the
address allocated.
                                                   CGA identifier
Bind the identifier
                               DHCP Solicitation
 and the address.
       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 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!

								
To top