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)