Control Plane Security Overview

Transcription

1 Control Plane Security Overview Wes Doonan Control Plane R&D

2 Hybrid Networks Packet-based Delivery ( ) Packets delivered via standard IP infrastructure Routes configured or learned, packets forwarded per addressing Flow-based Transport ( ) Flows delivered via dynamic path reservation Transport elements explicitly provisioned, dedicated pathways 2

3 Exploits Similar threats to both Packet and Transport Networks Denial of Service Theft of Service Interception of Service Traffic Analysis Achieved through different mechanisms Packet networks exposed to malicious L3 applications Exploits can be launched from L3-capable hosts Transport networks operate at L2/L1; therefore immune? Nope transport services created using L3-based mechanisms Disrupt the creator/manager, disrupt the service Need to adapt existing risk analysis and threat response techniques to new methods of exploit 3

4 Accessing the Control Plane Control Plane (CP) protocols Resource discovery via OSFP-TE Resource reservation via RSVP-TE Provisioning via GMPLS, UNI/NNI CP often run over a separate data network OSC, ECC channels, embedded with transport element Physical separation prevents access CP sometimes run on shared data network Overlay network on common IP packet network No longer physically separate, additional measures necessary to prevent access Control Plane Data Plane What if attacker could gain access to Control Plane messaging? 4

5 Denial of Service Packet: attack on forwarding plane Service based on ability of router to process packets Attacker must take down forwarding plane Flood of packets to overwhelm forwarding capability of router Requires ability to generate large inbound flows (botnets, etc) Byzantine exploit of router (packet-of-death) Relies on unfound/unpatched errors in router implementation Transport: attack on reservation capability Service based on explicit reservation of bandwidth Attacker must deny/falsify control traffic Spoofed PATH-ERR/PATH-TEAR message, to interrupt session Spoofed PATH message, to deny bandwidth to new sessions M-i-M on user PATH message, to corrupt and thus trigger denial 5

6 Interception of Service Packet: attack on the routing fabric User traffic generally follows path determined by routers Access to physical infrastructure Via social/environment engineering, other techniques Injection of falsified routes into routing fabric Byzantine exploit of unpatched or unsecured router Transport: attack on the reservation request User traffic follows path specified in reservation request Attacker alters the request, enables traffic intercept M-i-M on user PATH message, to modify ERO New ERO redirects user traffic through intercept point M-i-M on user RESV message, to hide alterations in RRO [ more complex than this, but if high enough value... ] 6

7 Traffic Analysis Packet: statistical analysis of data flows Specific flow not identifiable from single packets Flow semantics determined by applications Flows inferred from payload interpretation Long-term analysis of packet contents over time Correlate shared payload characteristics with addressing data Implies access to physical infrastructure (e.g. to sniff/snoop) Transport: interception of control messaging Control messaging specifically identifies flows Attacker can intercept control messaging to perform traffic analysis PATH/RESV carry wealth of session-related information No need for lengthy capture, inferencing or correlation 7

8 Results Control Plane protection is advisable The nature of provisioned services makes CP a target Amplifying effects Good practice to protect control traffic regardless Control Plane protection is possible Data network separation, where practical Inherent in some transport networks, though not always Existing protocol-level mechanisms available today Risk now is likely low, but wise to be aware of potential R&E networks favor collaboration over demarcation Appropriate, according to mission Awareness of possibility for exploit is necessary first step 8

9 Mitigation Protocols can provide their own protection mechanisms OSPF Authentication mode MD5 MAC per message Pre-shared keys Integrity only RSVP Integrity Object MD5 MAC per message Pre-shared keys Integrity only 9

10 Mitigation Run Control Plane on secure IP infrastructure (e.g. IPsec) Establish bidirectional SAs between protocol peers Apply desired level of protection (ESP) Separates protection mechanism from Control Plane OIF UNI/NNI Security 2.x approach More/better options than per-protocol facilities Though can clash with use of Router-Alert in classic RSVP 10

11 Mitigation Threat Classifications and Available Mitigation Mechanisms (People still need to implement Policies) Disclosure Disruption Deception Usurpation Traffic Analysis Denial of Service Interception of Service Theft of Service Confidentiality IPsec ESP w/ encryption (RFC2406) IPsec ESP w/encryption (RFC2406) Integrity RSVP Integrity (RFC2747), OSPF Cryptographic Authentication (RFC2328), IPsec ESP w/authentication (RFC2406) RSVP Integrity (RFC2747), OSPF Cryptographic Authentication (RFC2328), IPsec ESP w/authentication (RFC2406) RSVP Integrity (RFC2747), OSPF Cryptographic Authentication (RFC2328), IPsec ESP w/authentication (RFC2406) Availability RSVP Graceful Restart (RFC5063), OSPF Graceful Restart (RFC3623) 11

12 References IETF OIF RFC2328 OSPF Cryptographic Authentication RFC2401 IPsec Architecture RFC2406 IPsec Encapsulating Security Payload RFC2747 RSVP Integrity Object RFC3623 Graceful OSPF Restart RFC4593 Generic Threats to Routing Protocols RFC5063 Extensions to GMPLS Resource Reservation Protocol for Graceful Restart OIF-SEP-01.0 Security Extension for UNI and NNI OIF-SEP-02.1 Addendum to the Security Extension for UNI and NNI 12

13 Thank You