Security and Routing

1. 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

2. 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

3. 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

4. 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?

5. 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

6. 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

7. 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 …

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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 …

20. 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

21. 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…

22. 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

23. 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

24. 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

25. 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

26. 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

27. NEXT • Bgp security stuff • The SIDR IETF group (secure interdomain routing)