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