13.07.2015 Views

Presentation - Cisco Knowledge Network

Presentation - Cisco Knowledge Network

Presentation - Cisco Knowledge Network

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Routing SecurityAn Holistic Overview of ISP Secure RoutingGunter Van de VeldeBertrand DuvivierPranav Mehta1


click here© © 2010 <strong>Cisco</strong> and/or its its affiliates. All All rights reserved.<strong>Cisco</strong> Confidential 2


• Objectives of this talk:• Present a series of threats and potentialrouting-based (BGP) solutions to addressthem• Provide an overview of where to use whatsecurity mechanism• Explain some of the security mechanismsor solutions and its operational model• Have open discussion on futurecollaboration© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 3


Why do I Care?Security IntegrationObjectives Infrastructure ProtectionMalformed Attribute HandlingValidating Routing© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 4


© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 5


Goal:Enhance the overall security posture of <strong>Network</strong> infrastructure withRouting technologyCustomer Challenges:<strong>Network</strong> Availability:Business productivity impacted by outages caused by securitybreaches<strong>Network</strong> Design Complexity:Security devices lack network intelligence, forcing suboptimal <strong>Network</strong>designsLegal and Regulatory:<strong>Network</strong> security is an audit item and requires resourcesSolutions:A. Security IntegrationRouting technology as part of security portfolioB. Infrastructure ProtectionHardening the infrastructure© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 6


Biggest Bandwidth• Largest monitored attack in 2009,BPS:• 49.99Gb/sec, Port Range, Taiwan• Lasted 1 hour 19 mins• Largest monitored attack in 2010,BPS:• 66.205Gb/sec, DNS, US• Lasted 3 days, 21 hours and 18minutes• Largest monitored attack in 2011,BPS:• 79.27Gb/sec, Port Range, NZ• Lasted 2 hours 6 minsBiggest Packet/Second• Largest monitored attack in 2009,PPS :• 55.47Mpps, HTTP, US• Lasted 17 hours 1 minute• Largest monitored attack in 2010,PPS:• 108.89Mpps, DNS, US• Lasted 3 days, 21 hours and 18minutes• Largest monitored attack in 2011,PPS:• 71.34Mpps, HTTPS, US• Lasted 1 hour 29 minutes© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 7


Problem: Attack on theDevice Control Plane,DDoS BGP attackResolution: ControlPlane policing (CoPP orLPTS)Threat: Address Hijackingpushes customer to falseweb siteResolution: Origin ASAuthentication & SIDRprovide securityProblem: Am I Peering towith the correct peer?Resolution: NeighborAuthentication (MD5Keychain/TCP-OA)and IPSEC protectionof the BGP TCPsessionISP 3Inter-ASResolution: Dropunsent LabelsProblem: Inter-AS OptionB Label issue ISP 2Threat: False BGPPeers connectResolution: MaxTTL Protection(GTSM), LPTS, MD5,Keychain/TCP-OAAttack with BGPpolicy - Malformedupdates,attributed,AttributeFiltering,errorhandlingISP 4Resolution: Originauthorization & SIDRauthenticate routesProblem: How do Icentralize my securitymodelResolution: BGP FlowspecISP 1Threat: DDoS traffic issent into the <strong>Network</strong>attacking theinfrastructureResolution: RTBH,Blacklist VRF, SinkholeRouting, FlowSpecThreat: Partner injectionof false routinginformation disruptsbusiness© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 8


ThreatsAttack on device control planeFalse BGP peers connect , Attack using TCP,DDOS BGP attackInjection of fake/modified routes by a peeringpartner - Attack against IP prefixes and ASnumbersDDoS traffic is sent into the network and andattacks the infrastructureInter-AS option B label securityHow do I centralize the security modelAm I peering with the correct BGP peer?Malicious hijacking of the prefixes with theintent of performing Interception attackAttacks with Routing Policy and BGP routeattributesResolutionControl plan policing (CoPP/LPTS)Max TTL protection (GTSM), LPTS, MD5,Keychain/TCP-OASecure origin validation and AS-Path Validation- SIDRRTBH, blacklist VRF, sinkhole routingDrop unsent labelsBGP FlowspecNeighbor authentication (MD5 authenticationand TCP-AO) and IPSEC session protectionOrigin AS validation and SIDR (As-pathvalidation)Flexible RPL, BGP attribute filtering, BGPerror-handling draftBlack: exists at <strong>Cisco</strong> - Red: Future© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 9


Inter-AS Option B LabelSecurityBGP Attribute handlingand filteringISP3Enhanced filtering(RPL, Route-map)Control PlaneProtection (CoPP,LPTS)BGP FlowspecISP2GTSMProtectionthrough originRPKIISP1Traffic steeringthrough RTBHRouting Protocol always on authentication(MD5, TCP-OA/Keychain)© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 10


© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 11


Integration of security appliances force suboptimal networkdesigns that limit overall performance and availability• Security Device Layer 2 limitationsRequires Spanning Tree - blocked links & loopsLimited topology options – bridging, vlans, …Slower <strong>Network</strong> Convergence – L2 vs. L3 convergence• Security Device Layer 3 limitationsStatic RoutingRedistributionSlower ConvergenceOnly Some routing protocols support in-built security© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 12


Utilizing routing technology in the securityportfolio to improve network designs and enhancesecurity.• Security Device Routing Protocol EnhancementsL3 peering between redundant devicesDefault & Summary Route InjectionNSF/NSR, Graceful Restart & ShutdownFaster Failure Detection – Link up/down, BFD, PIC etc..Multi-instance BGP• Leveraging Routing Protocols as a SecuritytechniqueRemote Triggered Black HolesSinkhole Route InjectionBGP Flow Spec© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 13


Remote Triggered Black Holes (RTBH)Route Injected Black Hole• <strong>Network</strong> device begins sendingtraffic that is out of policy• Black/Sink Hole traffic by protocol,flow, SGT, or IP• Static RPL based config to assignblack hole nexthop• Routes Injected via BGP Flow Specpropagated to entire network• Black/Sink Hole could be initiated bya number of security devices ormanually by administrator• Traffic can be dropped at first L3network device or routed to sinkhole across network for inspectionBlack Holes injectedby network securitydevicesTraffic routed to centrallocation for loggingInfected or Attackingmachine’s traffic droppedwith Remote TriggeredBlack Hole at first routedhop© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 14


• Implementing blackholing requires two stages forconfiguration before CSCtb78915 and CSCtr79451• Creation of a static dummy /32 (IPv4) or /128 (IPv6) pointingtowards Null0• A routing policy that sets the next-hop towards the dummyaddress• Implementing blackholing requires one stage forconfiguration after CSCtb78915 and CSCtr79451• A routing policy to set next-hop to ‘discard’ for both RPL andRoute-map© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 15


Remote Triggered Black Holes using blacklist VRF• BGP routes can be inserted into any VRFbased on a simple community• The route can be generated on A, and acommunity attached that causes C and Dto place the route in the blacklist VRF• Now, as traffic is received, the sourceaddress is checked against the blacklist,and the packets are droppedHostAServerCDB• More advanced is that the traffic isdiverted into the VRF, scrubbed andforwarded• Traffic can be mangled in the VRF andreturned to senderOriginate routehere withblacklistcommunity Source is inblacklist, droppacketsAttack pathAttacker© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 16


Active/Active FirewallPre-2010 Operation• Firewalls do not participate in RoutingProtocolOut bound traffic tointernet gets NATedReturn traffic couldroute to originating FWIf traffic routed to otherfirewall packets mustbe punted back tooriginal firewall• No graceful way to take a Firewall out ofservice• Inefficient routing means both firewallshave to process same packet leading todecrease in performanceStatic routingbetween routersand FWs• Loses the benefit of rich routingfunctionality in <strong>Cisco</strong> networkinfrastructure• Lack of deterministic routing makestroubleshooting more difficultRtr injects DefaultRouteto route trafficgoing to Internet© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 17


Active/Active FirewallEnhanced L3 Firewalls• Firewalls Participate in Routing ProtocolImproves Active/Active and Active/Standby configurations (potentialfor simple Active/Active with no virtual contexts)• Default and Summary route injectionStandby injects routes with higher cost or route injection can beconditional• Improved Firewall FailoverLink-up/down L3 neighbor lossGraceful Restart and ShutdownFirewall failover = routing protocol failover time• Active/Active L3 designs Optimized.Each FW is Primary for a different NAT range and secondary fortheir peers NAT range (Multi-context)Out bound traffic tointernet gets NATedDefault Routein to attract trafficgoing outReturn traffic routed tooriginating FWFW advertises NATroute to Internet RtrStandby FWadvertises NAT routewith higher costStandbyFW/Contextadvertises Defaultroute with highercostEach FW can inject a Default and let the IGP provide the shortestpath to the FW out.• Optimized Routing with Conditional NATAdvertisementImproves efficiency of Active/Active FWs (minimizes doubleprocessing of packets)© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 18


Sink Hole RoutingIPS/IDS Enhancements• IDS (Intrusion Detection Systeam) ispassive and monitors the data traversethe network. If it detects anythingsuspicious – data pattern doesn’t matchthe expected rules, it sets off alarm.IPS Signalsother deviceto inject BHon its behalf• IPS (Intrusion Prevention System) sendsrequest for BH/ACL to drop subsequenttraffic based on pattern detected by IDS• IDS/IPS may peer with network devicesdirectly or signal central managementsystem to handle advertisements• For traffic that is out of policy traffic maybe marked/propagated via BGP FlowSpecIPS peers withrouter to injectBH/ACL?Router advertisesBH/ACLs to PeersAttack traffic droppedat first router© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 19


© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 20


Hardening the infrastructureOlder SolutionsHardening of the Routing Infrastructure from evolvingattacks is configuration intensive and vulnerable to securitygaps.• Current Protocol & Control Plan Protection• MD5 Authentication is dated, control plane intensive and rarelyused• Passive Interface & Peer ACLs are manually configured• CoPP is complex and rarely used for routing protocols• IPv6 specifies IPSec Authentication and Confidentiality ofRouting Protocols© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 21


Hardening the infrastructureEnhanced Technologies• CoPP Enhancements for Routing – GTSM,Keychains etc.• DCoPP/LPTS: Every Control and Managementpacket from the line card is rate limited in hardwareto provide flood protect at RP• Routing Core Auto-Protection• BGP FlowSpec: Automation of Filtering• Enhanced Authentication and Confidentiality• IPSec support for Routing Protocols• TCP-OA: MD5 Alternative with improved keymanagement to roll over keys periodically© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 22


CoPP Enhancements for Routing• Attack against the routing devices in thenetwork core• Current SolutionGTSM• TTL based filtering• TTL of 255 set on the routergenerating BGP updates• TTL value checked on the inboundinterfaces and dropped the packet ifreceived TTL is not 255• Allows protection for directlyconnected peering or LoopbackpeeringAccess Distribution CoreDefense onrouter interfaceAttack© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 23


CoPP Enhancements for Routing• The Problem: Attack against devices inthe network core• Advanced SolutionAuto Infrastructure Protection• Links automatically marked (withmanual override)• Traffic blocked at earliest possiblepoint in the network• Ideally, blocking would occur inhardwareAccess Distribution CoreDefense onrouter interfaceAttackDefense at edgerouter© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 24


• Main function is to forwards for-us packets to the right RP, DRP, orLC CPU• Secondary function is to provide protection against DDoS andprovide Control Plane Protection• IFIB (Internal Forwarding Information Base) used to match flowsImplemented in TCAM hardware• Matches IP and transport header fields, packet type, interface• Accepted/Configured flows are policed at higher rate• Unwanted flows are policed at lower rate - Unwanted packetsdropped quickly• Secondary look-up on RPs used to cover TCAM update latency© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 25


packets inControl Plane TrafficLPTSApp 1RPUser TrafficLCFIBtransitpacketsoutfor-uspacketsDCoPPDynamicControl PlanePolicingLPTSInternal FIB(IFIB)badpacketsgoodpacketsApp 2LocalStacksRPLC• LPTS is transparent and automatic© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 26


• LPTS has HW policers on line cards to limit traffic sent to(D)RPs• LPTS entries in TCAM classify packets to select apolicer• Protocol Slices are pre-configured on the Linecards• Polices on protocol (BGP, OSPF, SSH) and flow state(BGP established flows, BGP listen)• Policing done on the LC ASIC before packets hit RP/LCCPU• All filters are automatically and dynamically installed bythe IOS XR infrastructure• Provides protection against DDoS and does GTSMvalidation© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 27


TCP Handshake• DCoPP is an automatic, built in firewall for control plane traffic.• Every Control and Management packet from the line card is rate limitedin hardware to provide flood protect at RPLC 1 IFIB TCAM HW EntriesLocal port Remote port Rate PriorityAny ICMP ANY ANY 1000 lowany 179 any any 100 mediumany 179 202.4.48.99 any 1000 medium202.4.48.1 179 202.4.48.99 2223 10000 medium200.200.0.2 13232 200.200.0.1 646 100 mediumttl255LPTSSocketBGPLDPLC 2 IFIB TCAM HW Entries …SSH


Enhanced Router Authentication / ConfidentialityProblems today:• MD5 Authentication is dated, soft,control plane intensive and rarely used.• More powerful algorithms available• IPSec deployment is limitedSolutions:• TCP-AO: TCP Authentication Object• TCP-AO extends The md5 technology to support timebasedkey rollover and multiple hashing algorithms.• The goal is to use the update the key that is used tocreate a message digest for each TCP segment.• Based upon the perceived threat level the operator canselect the hashing algorithm to create the messagedigest.ISP3 ISP2 ISP1ISP4RoutingAuthenticationapprovedRoutingAuthenticationdenied!Attack© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 29


Securing Inter-AS VPN Confidentiality• What is Inter-AS Option B?• One of the methods to exchange VPN routes between twoAutonomous Systems, as described in RFC 4364, is “Option-B”.• With Option B the ASBRs allocate rewrite labels for VPN prefixesreceived both from the peering ASBR and internal peers within thelocal AS. Traffic forwarding is achieved by swapping the incominglocal label with label received from peers• What is the issue with Inter-AS Option-BThis type of connectivity suffers from security risks primarily arisingfrom the fact that the peering router can send labeled traffic with alabel value that was not advertised to the peer.This can lead to the following potential security violations:• The peer can send illegal traffic to a router within the local AS• The peer can cause the local router to illegally forward traffic fromthe peer to an unrelated router in a completely different AS© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 30


Securing Inter-AS VPN Confidentiality• How to mitigate the BGP Inter-AS Option-B confidentialitythreat?• BGP installs the list of labels advertised to the Peer (on externaleBGP peering interface) into the LC• When the local ASBR receives a labeled packet from an externalpeer, the local router must ensure the top label was previouslyadvertised to the source of traffic• The label stack on the packet received from the external peermust contain at most one label© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 31


Distribution Automation of Security Profiles• The problem:• Providers have limited options for mitigating DDoS attacks intra-AS as well as inter-AS• BGP destination black-holes: Portects against the attack butrequires static configuration• BGP src/uRP: difficult for some spoofed attacks and/or supportlarge numbers of sources• Access-Lists: difficult to maintain and occasionally dangerous toinstall• Need dynamic way of conveying info about threat and attack• The Basic IdeaUse BGP to distribute flow specification filters anddynamically filter on routes© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 32


Distribution Automation of Security Profiles• The Operational Principle• Encode flow specification rules as a new BGPNLRI address family• BGP itself treats the FlowSpec NLRI as anopaque key to an entry in its database• Use extended communities to specify action(accept, discard, rate-limit, sample, redirect)• Match on combination of source/dest prefix,source/dest port, ICMP type/code, packet size,DSCP, TCP flag, fragment encoding, etc.• Example: all TCP port 80..90 packets to 192.168.0/24© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 33


Distribution Automation of Security Profiles• Flow Spec trust model• Unicast routing advertisements control traffic getsforwarded• Consider a filter as a “hole” in the aggregate of trafficthat is being forwarded to a destination prefix• Accept filter when advertised by next-hop for thedestination prefix• Flow Spec Benefits• Fine grain specification of filters with BGP’sease of deployment/management• BGP solves distribution and trust problem• Leverage ASIC filtering in routers© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 34


© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 35


• Attribute filtering• Unwanted optional transitive attribute such as ATTR_SET,CONFED segment in AS4_PATH causing outage in someequipments.• Prevent unwanted/unknown BGP attributes from hitting the legacyequipments.• Block specific attributes• Block a range of non-mandatory attributes• Error-handling (draft-ietf-idr-optional-transitive-04.txt)• Punishment should not exceed the crime• Gracefully fix or ignore non-severe errors• Avoid session resets for most cases© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 36


Malformed BGP UpdatesInvalidAttribute ContentsWrong AttributeLengthValid BGP UpdatesUnknown AttributesUnwanted AttributesAttribute FilteringError-handlingNLRI processing…© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 37


• First level of inbound filtering - Protection againstmalformed update• Filtering is configured as a range of attribute codesand a corresponding action to take• Actions• Discard the attribute• Treat-as-withdraw• Applied when parsing each attribute in the receivedUpdate messageWhen a attribute matches the filter, further processing ofthe attribute is stopped and the corresponding action istaken© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 38


• Comes into play after attribute-filtering isapplied• When we detect one or more malformedattributes or NLRIs or other fields in theUpdate message• Steps- Classification of errors- Actions associated with the type of error- Logging for debugging / corrective action© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 39


• Classification of errors• Minor: invalid flags, zero length, duplicates, optionaltransitiveattributes• Medium: Non-optional-transitive attributes, inconsistentattribute length• Major: Invalid or 0 length nexthop• Critical: NLRI parsing, inconsistent message / totalattributes length• Actions taken• Local repair• Discard attribute• Treat-as-withdraw• Reset session• Discard Update message© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 40


© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 41


• Incorrect Origin AS announcements- Source and announce prefix with incorrect origin AS- Source and announce a more specific prefix belonging tosomeone else• Incorrect Path announcements- Hijack a BGP path for a prefix by inserting local AS• Ends up hijacking someone else’s traffic by getting itrouted to/via you• Capture, sniff, redirect, manipulate traffic as you wish• Most often a configuration mistakeSource: NANOG 46: Tom Daly et al.© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 42


20Source: NANOG 46: Tom Daly et al.© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 43


Source: NANOG 46: Tom Daly et al.© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 44


BeforeAfter© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 45


ASN100 advertisesmore specifics for10.10.220.0/22keeping origin ASand its forwardingpath intact (10 20200)10.10.220.0/22© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 46


• http://www.networkworld.com/news/2009/011509-bgp-attacks.html• bgpmon.net© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 47


• Any AS can inject any prefix in BGP: “Fat fingering” or“Malicious”• Solution in two parts:Mechanism to verify origin AS of a prefix : Origin ValidationMechanism to verify the path of the prefix announcement: PathValidation• IETF SIDR WG has defined a framework based on RPKI(Resource Public Key Infrastructure)• Initially targeted for BGP Origin Validation solution. Will beextended to support BGP path validation solution• Rest of the slides provide an explanation of this framework, keepingorigin validation in mind© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 48


• The goal of the RPKI is to cryptographically verifyassociation of Autonomous Systems and its IPaddresses• The RPKI builds a structure where each AS cantrust what another AS says about prefixownership even if they don’t have a businessrelationship with that AS.• Leverage the current model for prefix allocation tocreate trust hierarchy• Define certificates and various signed objects to forma repository that can be referenced to validate BGPannouncements© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 49


• RPKI starts with each RIR (ReginoalInternet Registry) generatingcertificates for each prefix it assigns,and distributes that certificate alongwith the prefix.The certificate says “I’m giving thiscustomer of mine prefix , and you canprove I said this by validating that I signedthis certificate with my public key”Getting the public key is straightforwardusing the usual PKI methods.• Each ISP sub-allocating prefixblocks makes the same statementsBut the ISP can only distribute morespecifics of those they have beenassigned.Signature© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 50


• Each AS publishes a cryptographically signed “ROA” (RouteOrigin Authorization) that declares association of its prefixeswith an Origin AS.ROA98.128.0.0/16-24AS 3130Signature• The ROA says “I’m authorizing AS to be the origin for prefix ”and you can prove this by verifyingthe signature on this ROA.”• The ROA is verified with the publickey of the organization creating theROA, which will be available to theverifier because it has the certificateof the AS.© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 51


IANA0/0CAPublic Key IANASigned by IANARIPE37/8CAPublic Key RIPESigned by IANAOrgX37.1/16CAPublic Key OrgXSigned by RIPE(CA)OrgX37.1/16EEPublic Key OrgXSigned by OrgX(EE)ROA37.1/16-24AS XSigned by OrgX(EE)© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 52


CA ToolsetPublicationpoint (can behostedelsewhere/by 3 rdparty)RPKIbackend(Repositorytree walk &certificatevalidation)RPKI-RTRServerRPKI-RTRClientBGP© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 53


BGP Border Router- Receive prefixes from IBGP & EBGP peers- Inline origin validation by looking up validation database- Event-based validation on cache updatesAF specificPrefixValidationdatabaseCache-to-routerprotocol (TCP, TCPwith authentication,or SSH)AF SpecificBGP tableseBGPpeeringiBGPpeeringIBGP Neighbor Router(ex. Route Reflector)RPKI Validator (cache)EBGP Neighbor Router© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 54


EBGP updateRouterCheck and markorigin validityApply inbound policy(policy may match onvalidity state and setarbitrary attributes)Add to ADJ-RIB-INRun (best path)decision processIBGP update(advertised with theset attributes frominbound policyexecution and withorigin validationextendedcommunity)© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 55


• Does this work address all the problems in therouting database space?• No....- But it’s not really intended to- It’s intended to be a first step• Things to Ponder- The “one behind” attack- The “longer prefix” attack- The “shorter prefix” problem- Centralization of Authority© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 56


The “One Behind” Attack• AS65000 advertises10.1.1.0/24• This is the valid originator• AS65010 advertises10.1.1.0/24• With a “ghost” AS Path• Makes it look like AS65000 isattached to AS65010• How can AS65020 tell whichadvertisement is valid?• You must validate more of theAS Path to find the validadvertisement10.1.1.0/24AS6500110.1.1.0/24AS65000AS6502010.1.1.0/24AS65010AS65000© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 57


The “Longer Prefix” Attack• AS65000 advertises10.1.1.0/24• This is the valid originator• AS65010 advertises10.1.1.0/25 and 10.1.1.128/25• Use the “ghost AS trick”• AS65020 will route traffic destined toAS65000 to AS65010• You could make the certificatesreplicate the advertisements,but this adds a lot more state• One compromise is to markwhat the longest advertised willbe within a blockAS65001AS65000AS65020AS65010AS65000© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 58


The “Shorter Prefix” Problem• AS65000 advertises10.1.1.0/24• This is the valid originator• AS65000 doesn’t want AS65020 tobe able to reach 10.1.1.0/24• So, it marks 10.1.1.0/24 so it’s notadvertised to AS65020• AS65001 advertises a default toAS65020• Hence, AS65020 still hasreachability to 10.1.1.0/24• The only possible solution is tohave some sort of a fine grainedpolicy—honored by all parties—ona per AS pair basisAS65020AS65001AS65000© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 59


Centralization of AuthorityFuture• If the RIRs have the only valid certificate database....- What if you get into a billing dispute with the RIR?- Can they shut down your business while it’s resolved?- What if two governments go to war, or sanctions are imposed bysomeone on someone else?- Will the RIRs be able to “pick sides?”- Do the RIRs really want to be in the middle of these sorts ofpolitical situations?- Do the Service Providers?- What if someone’s origination is successfully stolen?- Who gets sued? For how much? By whom?• Lots of questions for which there are no clear answersyet....© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 60


Future• Start Here• AS65000 advertises 10.1.1.0/24• AS65020 receives the advertisement for10.1.1.0/24 with the AS Path {65000,65001}• There are at least two meanings• Showing a specific advertisement of specificreachability information has actually passedthrough a specific set of AS’• AS65020 can prove the advertisement for10.1.1.0/24 actually passed through AS65001• Showing a specific AS Path exists within thenetwork• AS65020 can show AS65000 is actually connectedto AS65001• AS65020 can show AS65001 is actually connectedto AS65020AS65020AS65001AS65000© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 61


Future• Advertisement ValidationThe route advertisement may be validated by each AS in the pathsigning the route advertisement itselfPath Validation enables forward signing i.e.AS65000 gave the update to AS65001 andAS65001 gave the update to AS65020• Path Validation• The AS Path may be validated using a number of means• Generally relies on either pairwise AS connectivity information orsome form of statistical analysis of the routing database state• For this presentation, we assume some form of pairwise ASconnectivity information is used to validate the path© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 62


Advertisement vs. Path Validation• Some basic assumptions• You cannot “secure” attributes (communities, nexthops, etc.)• You cannot know data will flow along the AS Pathgiven in the routing advertisement, and it has not beenthe original goal of Path Validation• The control plane and data plane are only loosely coupled• Tight coupling would defeat the point of packet based networks• Origin authorization is separate from path validation• Some policies cannot be enforced if they are “secret”© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 63


Advertisement vs. Path Validation• Is one “more secure” than the other?• It all depends on what you mean by “more secure”• Releases more information about your AS boundaries?• Harder to “fool?”• There’s no definitive answer to this question• Is one “more deployable” than the other?• Path validation kills update packing• Path validation requires real time encryption across alladvertisements• Path validation requires larger database space and (probably)more complex processing• Path validation appears—overall—to be rather difficult to deploybecause majority of the Internet must support this to reap thebenefits• Path validation is susceptible to replay attacks, given thetimescales of operation© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 64


• What are Bogons?A bogon is a bogus IP address, and an informal name for an IPpacket on the public Internet that claims to be from an area of the IPaddress space reserved, but not yet allocated or delegated by theInternet Assigned Numbers Authority (IANA) or a delegated RegionalInternet Registery (RIR).The areas of unallocated address space are called the bogon spaceMany ISPs and end-user firewalls filter and block bogons, because theyhave no legitimate use, and usually are the result of accidental ormalicious mis-configurationIANA maintains a list of allocated and reserved IPv4 netblocks• How to filter Bogons?Usage of RPL or Route-maps© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 65


• BGP is become a new Transport Protocol – IP Prefixes,L3VPN, L2VPN, MVPN, Security, EVPN etc.• In Traditional BGP, all address-families (IPv4, IPv6, VPN,etc…) have the same resource priority• Often there is a need to have some priority amongst thedifferent address-families• If one address-family is using too much resources, it canstarve out the resources for the other address-families• If one address-family corrupts the BGP data-base all otheraddress-families are impacted –• Process crash• CPU starvation• OOM• Need to provide some protection/isolation for betterresiliency/reliability© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 66


• Multi-Instance / Multi-AS BGP• Priority Address-Families can be placed in a dedicatedisolated instance• Non-critical Address-Families can go into a secondprocess• This makes sure that the priority address-family getsdedicated resources and isolates the BGP databasefrom negative impact of the non-priority instances• Moving separate AF into its own instance can provideCPU/Memory isolation and better protection© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 67


• <strong>Cisco</strong> has been constantly and actively working on improvingBGP/Routing security• Various leads from <strong>Cisco</strong> are involved with IETF activities in IDR,SIDR as well as OPSEC and have co-authored various IETFdrafts in this area.• <strong>Cisco</strong> has implemented large number of features in BGP andoutside of BGP that would provide security and protection• Pro-active features are implemented to provide the protectionagainst malformed updates or rouge peers• <strong>Cisco</strong> is continuing its focus to provide more solutions to protectagainst ever increasing DDoS attacks.© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 68


© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 69


Thank you.© 2012 <strong>Cisco</strong> and/or its affiliates. All rights reserved. 70

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!