Source Address Validation: from the Current Network Architecture to SDN-based Architecture

Transcription

1 Source Address Validation: from the Current Network Architecture to SDN-based Architecture Jun Bi Tsinghua University/CERNET GFI 2013 Nov. 20,

2 Content Source Address Validation Architecture (SAVA) SAVA solutions SAVA Implementations SAVA deployment at CNGI-CERNET2 Leveraging SDN to enhance Source Address Validation Access: Software Defined SAVI Intra-AS: SDN based CPF Inter-AS: Collaborative On-demand Spoofing Defense Conclusion 2

3 Source Address Validation Architecture (SAVA) 3

4 Source Address Spoofing Source address spoofing still a problem Arbor Network annual network security report MIT spoofer project NANOG discussions Tsinghua university / CERNET proposed: Source address validation architecture (SAVA) and solutions for IPv6 Solutions implemented, collaborating with domestic vendors Deployed at CNGI-CERENT2 backbone and 100 universities campus networks Co-funders of IETF SAVI WG RFC 5210 SAVA RFC 7039 SAVI Framework 4

5 SAVA: Source Address Validation Architecture (RFC 5210) Transit AS AS Level Granularity AS Inter-AS AS IP Prifix Prefix Level Granularity Intra-AS Access Network Access Network Interface ID Level Granularity Access Network 5

6 Access Level: SAVI-CPS (Control Packets Snooping based SAVI) SAVI-DHCP SAVI-Stateless SAVI-MIX 6

7 SAVI-CPS Implementation Huawei ZTE H3C Ruijing Digitial China Centac Bitwa L3/L2 switch, WLAN 7

8 Intra-AS Level: CPF (Calculation based Path Forwarding) SNMP collect routing table and interface table Calculate Path xflow collect sampling info Path Table Generate FTDB FTDB Telnet+Scripts configure ACL Key problem to resolve - Reduce false positive caused by urpf at partial deployment FIT Src (inif1)a1 (inif2)a2 (inifn)dst Src, Dst, inif Src, Dst, inif FIT: Flow Info Table Match (Alarm) FTDB: Filter Table DB

9 CPF Implementation Topology mgmt L3 devices mgmt Spoofing alarm SAVI user mgmt 9

10 Inter-AS Level: SMA (State Machine based Authentication) Key problem to resolve Incentive for deployment Trust Alliance ACS Each member AS has a control server to negotiate parameter of SMs of each peer to trigger the same tag (random number) sequence ASBR Add tags in IPv6 packets (in option header) and validate tags in destination Incentive source address of Each AS can t be spoofed within the Alliance 10

11 SMA Implementation Huawei NE40E core router line cards with 10G, GE ports Bitway BE12000 core router line cards with OC48, GE ports Centec special box with 10G, GE (co-located with legacy routers) 11

12 SAVA Deployment at CNGI-CERNET2 6IX Inter ISP (SMA) Inter AS (SMA) Intra-AS (CFP) AccessNet (SAVI-CPS) 12

13 SAVA Deployment at CNGI-CERNET

14 Leveraging SDN to enhance Source Address Validation 14

15 Motivations: enhancing Access Complex scenarios Address assignment methods: Manual, SLACC, DHCP, SEND, Mixed, Access methods: LAN, WLAN, DSL, 3G, Mobility: local, across-network Special cases: IPv6 transition, DNA, addr. related new stuff Solutions implemented at switches for all scenarios Complex for design and implementation Low efficiency (most scenarios are not common cases) Complex configuration Coherent configurations for ALL switch ports at SAVI perimeter in the whole access network Can we migrate complexity from switch to server?

16 Software Defined SAVI (SDN-SAVI) Control Plane Rule Generator Data Plane Binding Rules SAVI Switch Controller NOS Message Adaptor Data Plane Binding Rules OF Messages SAVI APP1: state machine SAVI APP2: rule generator SAVI APP3: mobility SAVI APP4:.. SAVI Switch

17 Motivations: enhancing Intra-AS Complexity to deal with legacy management and control interfaces No unified MIBs (private MIBs) No unified sampling protocol (sflow, NetFlow, NetStream, etc) No friendly programmable interfaces to configure ACLs (telnet + scripts are dangerous for production nets) Performance Delay of network status update Delay of control update Require unified and realtime mgmt/ctrl interfaces

18 SDN based CPF Control Plane Global view CPF Network APP SNMP xflow TCL telnet NOS(Network OS) OpenFlow Protocol Data Plane

19 CPF Address Validation Module Filter Generator Module NOS-NAPP Rule Adaptor Module NOS Packet Sample Message Processor NOS-NAPP Protocol NOS-NAPP Network State Message Processor OpenFlow Control Rule Message Processor OpenFlow OpenRouter Switch OpenFlow+ Protocol OpenFlow Control Plane Data Plane RTM OSPF BGP RIP xflow QoS&ACL FIB

20 Filtering Rules Enforcement Delay causes false positive, reflects the filtering effect

21 Demonstrated at INFOCOM2012 InSAVO: Intra-AS IPv6 Source Address Validation Solution with OpenRouter Central Control: To get a global forwarding path and then resolve false positive of filtering information caused by asymmetric routing more than ingress filtering. Integrated Protocol: To takes place of SNMP/xFlow/Telnet in order to reduce the complication caused by multiple control interfaces with OpenFlow protocol. Evolvable Deployment: To provide software-defined abilities by extending OpenFlow, but also give a tradeoff between existing hardware and evolution cost.

22 Motivations: enhancing Inter-AS Security: SMA uses lightweight tags for verification. An attacker might monitor packets in the backbone and replay the tag with spoofed packets Solution- cryptographic tags to prevent replay Cost: Per-packet crypto marking incurs heavy data processing overhead beyond hardware capacity. Solution- on-demand defense to reduce overhead When : defend only attack is detected (cost effective) Which : define N defense functions, chosen by operators by the type of attack Who : only filtering the specific flows with self-benefit

23 CoFence: Collaborative On-demand Spoofing Defense Distributed inter-as collaboration Deployer discovery, peering and defense invocation Spoofing defense functions Against d-dos: DP and CDP (CDP uses crypto marking) Against s-dos: SP and CSP (CSP uses crypto marking) Extensible: can define more functions Function invocation Quadruple: (function, parameters, prefix, time) Function: the function to be invoked Parameters: parameters for the function (e.g., keys for crypto) Prefix: the src/dst prefix to be protected Time: the time duration for this invocation These lead to SDN-based design

24 SDN (not OpenFlow) based CoFence Higher-layer features can be added in apps, e.g., attack monitoring, traffic analysis, AS-wide policy and control, manual-config GUI and auto-config APIs for IDS. Apps Controller Controller communicates with other domains, and bridges apps with routers, using SDN interfaces. It provides CoFence-specific functionalities and maintains domain-wide information. policy monitor northbound interfaces policy loc info peer info GUI analysis on demand defense peering southbound interfaces API control east west interfaces secure C C channel Internet Apps Controller secure C R channel ibgp CoFence-d communicates with controller and manages tables to define data-plane behavior. Router SW CoFence d BGP d HW tables data flow ebgp Router AS i AS j

25 WE-Bridge proposed in FINE WE-Bridge proposed in China 863 High-tech R&D project FINE Demoed at CANS13 and SupterComputing2013 AS-1 (Doman 1) APP-1 APP-2 APP-n AS-2 (Domain 2) APP-1 APP-2 APP-n Logical View API VCP-1 IDN IDN VCP-2 NOS-1 IDN Global Physical View API WE- Bridge IDN NOS-2 Local View API DPA1 DPA2 DPAn DPA1 DPA2 DPAn Open Devices Open Devices

26 Conclusion SAVA and solutions Architecture Access level: SAVI-CPS Intra-AS level: CPF Inter-AS level: SMA Implementation, and deployment at CNGI-CERNET2 Leveraging SDN to enhance Source Address Validation Motivations Handling complexity Providing agility Improving performance Programmability is key to decoupling infrastructure and functionality (to migrate the complexity to APPs) Leveraging centralized view for access (e.g. configuration, mobility) and intra-as, and negotiated view for inter-as SAV 26

27 Thanks! 27