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)