Transcript Slides
Security and Routing • Source routing and tunnels • Routing security – Protocol – Content • IGP routing • BGP routing • Nothing new here: – Going on for years on the telephone network Security concepts • Authentication – I am who I say I am • Integrity – A message was not changed after it was sent • No Replay – Do not let me do the same thing twice • Confidentiality – Do not let other read my communication • Non-repudiation – Do not let me say something different later More concepts • Secure hash function – A hash that can not be reversed • Digital signatures – Protect documents – Authentication, non-repudiation, integrity – Digital certificates • Encryption • Symmetric cryptography – Both parties share a key • Public key cryptography – Each party has a public key • All can send to it • Public key infrastructure (PKI) – Public key cryptography is useless if I get a fake public key for talking to my bank – Need certificates for them Difficulties with security • Cryptographic operations may have larger CPU costs • Cryptographic information requires more storage • Key distribution and management is difficult – Especially on a global scale • Certificates need Trusted Authorities – Who are they? Can they be trusted? Threat model • I am an attacker outside the backbone network – Can not observe traffic inside the network – May be able to attack the routers • Limited: usually providers filter at the edge • I am inside the backbone network – Can observe traffic at one or multiple points • Switched Ethernet connections etc • Or tap into a point-to-point line, not too easy – Can attack all routers – Can not arbitrarily drop traffic • Simply drop HELLOs to bring peerings down • I have compromised one router already – The we are in trouble… • Can drop packets • Can attack the routing system directly What is the attacker’s goal • Bring the network down – Will be detected • Disrupt the network but do not bring it down – Stealthy, may be undetected – Make it appear as if it is caused by external causes • E.g. fake BGP information • Bring some destinations down – Maybe hard to detect – Make it appear as it is externally caused – BGP • Hijack the traffic – Send it through some monitoring point – Black hole it – Make it loop There are a lot of holes • ARP: – Attacker can send its own ARP reply message and disconnect a node from the lan – Then it can hijack its session easily – ARP replies are sometimes unsolicited • Other systems will accept them even if there was not request sent • No need to even wait for an ARP request • ICMP – Has the very nasty “redirect” message – Can cause a system to use a different router • Which of course could be the attacker – This can and is usually disabled these days • IP source routing – I can add an arbitrary source route to any packet I can intercept – So I send it through the attacker’s premises for recording • And of course DNS … Spoofing • Source IP, port can be spoofed – This allows me to try to insert a packet into a existing TCP connection • Destination will admit the packet if it comes from the right source address/port – RPF check • Do not accept a packet from an interface that is different for the one I would use to reach its source • Not deployed everywhere • Routes can be asymmetric sometimes • Can spoof MPLS labels too – Can put a packet inside an existing LSP • Do not accept labeled packets in certain interfaces • Do not accept labels from interfaces that you did not advertise them Perimeter security – Providers guard the perimeter of the networks – Install packet filters that block access to the IP interfaces of the backbone routers • This prevents any kind of attack to backbone routers from outside the network • But difficult to keep the filter rules up to date on incoming links – Do not accept MPLS labeled packets from outside links • There may be cases that this is necessary • Accept only labels that were advertised to the peer – RPF check to drop spoofed packets – Point-to-point peering connections with other providers • Switched connections open the door to monitoring • Especially if we have to receive MPLS packet over it Attacks against routing • Make a peering session fail – TCP based vs. packet based • TCP is harder – May not be easy to detect • Could appear as a temp link failure • Insert false information into the peering session – Without having compromised the routers • Harder to detect – Can result in traffic hijacking • Attack the stability of the system – May have to achieve one of the above first – Cause flapping, resets of peering sessions, general routing overloading • Or just attack the routers directly – Crack the passwords to get administrator access – DoS Attacking routers • Like attacking a PC – Port scanning – Password cracking – DoS • ICMP is a good choice – Routers limit these very carefully • Send too much traffic with IP options set • DoS the links to cause peerings to reset • TCP SYN floods, bad packets etc… • Usually it is not possible to reach the interfaces of the routers directly from outside • Of course I can attack the routers if I am already inside the network Attacking TCP sessions • Can bring it down very easily – Just insert a TCP RST in the stream – But I need to guess the sequence numbers correctly – “TCP session hijacking” • Various levels – Must be able to physically insert packets in the link • Switched Ethernet or similar – Just insert a packet here and there • May be quite simple – “Man in the middle” • Put my machine in the middle and monitor/change all traffic • What will happen with ARP? • Need to get the victim to reply to the malicious node – ARP poisoning TCP session hijacking • TCP establishes sequence numbers at the beginning of the session – 3-way hand-sake – Other authentication (kerberos, passwords) happens at that time • If I can sniff the traffic I can figure out the current sequence numbers • If I can spoof the source information of the packet I can inject a packet into the stream – I have to do this before the legit part sends the packet with the same sequence number • Plenty of tools for TCP hijacking • Defences – Prevent spoofing – Prevent sniffing – Encrypt the exchanged information • This will not protect from RSTs that will shutdown the connection Attacking IP/UDP sessions • Simpler than TCP – Send packets directly to the router no need to guess sequence numbers – I can also spoof the source address of the packet to avoid filtering at the victim router – May have to be one-hop away from the router • It is always a good idea to rate limit all kinds of traffic – And not only ICMP and TCP SYNs • E.g rate limit RSVP traffic – Rate limiting will have to happen at the interface • If I receive the packets in the RSVP process I already burned a lot of resources, it is DoS • Rate limiting at interfaces is a bit expensive to do at high speeds Cryptography • Packets carry cryptographic information that proves they are “ok” – It does not really solve the DoS problem • A protocol will have to receive the packet and verify the crypto – Security processing is more expensive – Even worse potential for DoS now – Just send a lot of packets with bogus crypto • Protocol will choke trying to verify the crypto Protocol Security machinery • Use Message Authentication Codes (MACs) – Two peers agree on a password – Sender computes a MAC of each packet it sends • MAC is few bytes (64 usually) • Using the common password • MAC is sent along with the packet – Receiver re-computes the MAC • If it does not match what is in the packet it drops it • Else a match proves that sender knows the password • As safe as the passwords/keys used – And there are a lot of problems with passwords – No existing standard key management system What do MACs give us? • Authentication – I know the sender knows a secret so he must be a good guy • Integrity – The message has not been modified after it was sent • Replay prevention: – To avoid include a sequence number in each packet • OSPF has them, IS-IS does not! – An attacker can fake high sequence numbers • No Confidentiality – I can see the TCP headers • I can try session hijacking – I can see the contents of the message • Do not cover all the packet – IP/TCP headers are not part of the MAC • I can still spoof them MD5 and HMAC • A good MAC must be – Collision resistant: Very hard to find two messages that have the same hash – Pre-image attack resistant: Given a MAC very hard to find a message with this MAC – Second pre-image attack resistant: Given a message very hard to find another message with the same MAC • RFC2385 proposes to use the MD5 hash as the MAC – MD5 has started to show problems – It is possible to compute collisions effectively, in about 1hr in some cases – Other hashes may have problems too • RFC2104 proposes a Hashed MAC (HMAC) that is slowly starting to be used – The HMAC can be using MD5 internally but its security is better – MD5 is still used in BGP though • There has been a lot of noise about the security of MD5 recently – There are other issues that are much more important If MD5 is broken then… • How dangerous is this for routing protocols that use it as MAC? – Attacker wants to inject fake packets • First, he must have enough physical access and spoofing capability to send it – Need to find a modified message that has the same MAC as a good message • This is a pre-image attack • Not a collision attack, since I do not control both messages • MD5 has problems with collisions not pre-image attacks – Even if I could do a pre-image attack most probably I could not control completely the contents of the fake packet • I could change few bits here and there • May not be sufficient to do real damage at the protocol level • Just send a malformed IGP packet – If the receiving router is buggy it could cause a crash maybe … The real hard problems are: • How to manage passwords and keys – Errors, social engineering – stupid passwords and password policies • How to make sure that routers tell the truth – All the possible security in the protocol exchanges and the links can not protect me from a compromised router – it is difficult for IGP – Imagine how bad it gets for BGP/inter-domain routing • No central coordination • Minimal trust on the 10,000s of ISPs that participate in the system Intra- vs. Inter-domain Routing Security • Very different – Intra-domain routers are under a single administrative control • Same policies and best practices • Trust in the components of the system • Can enforce some security in the perimeter of the network – Inter-domain • Forget all that… How to verify IGP routing information – A bad router can trivialy bring its links down and in general disrupt the network • Will be detected easily – But can it lie so that is hijacks traffic undetected? – Some lies can be caught • A router lies about its links • The router at the other end of the link will not lie – The inconsistency may be detected • Unless more than one routers are lying More checks • Other lies can not be caught – A router lies that it has a stub network (without other router at the end) • If this stub network does not exist elsewhere in the network this lie can not be caught • Can hijack traffic this way - hijack a BGP route for example – Or a bad router claims to have high priority to become DR so it gets elected as DR – Need to know if a router can originate certain information • Requires some centralized configuration management tool • A bad router can send bad LSUs with spoofed router ids – Others can not trace the wrong information to the bad router – Need to provide origin authentication • A bad router can modify LSUs that it sees during flooding – Need to ensure integrity of LSUs Cryptography to help • Use public key cryptography – Proposed since 1997 • When a router R originates an LSU it signs it – Using its private key – Receivers can use R’s public key to ensure that it was indeed originated by R – This ensures origin authentication and integrity – To save time compute a hash of the LSU and sign the hash – Needs key infrastructure • Or flood the public key of each router through OSPF itself • But then public keys are not trusted • Need a certification entity that signs these public key records There are still holes • Router can silently drop packets – No protection against that • A router can advertise a non-existent stub network • ABRs can advertise wrong information for other areas – Given that there will be usually more than one ABRs can compare the information between the two to see if all is ok • ASBRs can advertise what they want – And there is not much that can be done • In all cases, if we observe something funny at least can find reliably who originated the wrong information – Since all LSUs are signed Is it deployed? • No. The risk-reward balance is not right (yet) – Security solutions are heavy • More CPU, decreased protocol performance, convergence and maybe stability – Threat does not seem to large • Filtering at the edge and best practices seem to control the problem • In intra-domain at least • In inter-domain things are bad but it is hard to solve anything – Huge scale – Minimal coordination between participants NEXT • Bgp security stuff • The SIDR IETF group (secure interdomain routing)