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 attackers 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 attackers 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 Rs 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)