1. Securing Key Internet Technologies Computer Security Peter Reiher March 14, 2017

2. Outline
Routing security
DNS security

3. Routing Security
Routing protocols control how packets flow through the Internet
If they aren’t protected, attackers can alter packet flows at their whim
Most routing protocols were not built with security in mind

4. Routing Protocol Security Threats
Threats to routing data secrecy
Usually not critical
Threats to routing protocol integrity
Very important, since tampering with routing integrity can be bad
Threats to routing protocol availability
Potential to disrupt Internet service

5. What Could Really Go Wrong?
Packets could be routed through an attacker
Packets could be dropped
Routing loops, blackhole routing, etc.
Some users’ service could be degraded
The Internet’s overall effectiveness could be degraded
Slow response to failures
Total overload of some links
Many types of defenses against other attacks presume correct routing

6. Where Does the Threat Occur?
At routers, mostly
Most routers are well-protected
But . . .
Several vulnerabilities have been found in routers
Also, should we always trust those running routers?

7. Different Types of Routing Protocols
Link state
Tell everyone the state of your links
Distance vector
Tell nodes how far away things are
Path vector
Tell nodes the complete path between various points
On demand protocols
Figure out routing once you know you two nodes need to communicate

8. Popular Routing Protocols
BGP
Path vector protocol used in core Internet routing
Arguably most important protocol to secure
RIP
Distance vector protocol for small networks
OSPF
ISIS
Ad hoc routing protocols

9. Fundamental Operations To Be Protected
One router tells another router something about routing
A path, a distance, contents of local routing table, etc.
A router updates its routing information
A router gathers information to decide on routing

10. Protecting BGP BGP is probably the most important protocol to protect
Handles basic Internet routing
Works at autonomous system (AS) level
Rather than router level

11. BGP Issues
BGP is spoken (mostly) between routers in autonomous systems
On direct network links to their partner
Over TCP sessions that are established with known partners
Easily encrypted, if desired
Isn’t that enough to give reasonable security?

12. A Counterexample
Pakistan became upset with YouTube over posting of “blasphemous” video (2008)
Responded by injecting a BGP update that sent all traffic to YouTube to a site in Pakistan
Which probably dropped it all
Rendered YouTube unavailable worldwide (well, 2/3s of world)
Probably due to error, not malice

13. How Did This Happen?
Pakistan injected a BGP update advertising a path to YouTube
Which they had no right to do
It got automatically propagated by BGP
Everyone knows YouTube isn’t in Pakistan
But the routing protocol didn’t
Security required to prevent other future incidents

14. Another Example
In 2010, China rerouted a lot of US traffic through its servers
Traffic purely internal to the US
Lots of military, government, commercial traffic
Based on bogus BGP route advertisements
Possibly errors, not attacks, but . . .

15. A Side Issues on This Story
Much Internet design assumes major parties play by the rules
Pakistan didn’t
Not desirable to base Internet’s security on this assumption
Though sometimes not many other choices

16. Basic BGP Security Issue
1.2.3.* A
1.2.3.*
B,A
1.2.3.*
C,B,A
1.2.3.*
D,C,B,A A B C D E
1.2.3.* A
1.2.3.*
What do we need to protect? F G
A wants to tell everyone how to get to *

17. Well, What Could Go Wrong?
1.2.3.* A
1.2.3.*
D,F A B C D E
What if A doesn’t own *?
What if router D alters the path? F G
What if router A isn’t authorized to advertise *?

18. Two Sub-Problems Security of Origin (SOA)
Who is allowed to advertise a path to an IP prefix?
Path Validation (PV)
Is the path someone gives to me indeed a correct path?

19. How Do We Solve These Problems?
SOA - Advertising routers must prove prefix ownership
And right to advertise paths to that prefix
PV - Paths must be signed by routers on them
Must avoid cut-and-paste and replay attacks

20. S-BGP One example solution
A protocol designed to solve most of the routing security issues for BGP
Intended to be workable with existing BGP protocol
Key idea is to tie updates to those who are allowed to make them
And to those who build them

21. Some S-BGP Constraints
Can’t change BGP protocol
Or packet format
Can’t have messages larger than max BGP size
Must be deployable in reasonable way

22. An S-BGP Example
1.2.3.* A A B C D E
1.2.3.*
A can provide a certificate proving ownership
How can B know that A should advertise *? F G

23. What are these signatures actually attesting to?
Securing BGP Updates
1.2.3.* A
1.2.3.*
B,A
1.2.3.*
C,B,A
1.2.3.*
D,C,B,A A B C D E
1.2.3.*
What are these signatures actually attesting to? F G
A wants to tell everyone how to get to *

24. Who Needs To Prove What?
A needs to prove (to B-E) that he owns the prefix
B needs to prove (to C-E) that A wants the prefix path to go through B
C needs to prove (to D-E) the same
D needs to prove (to E) the same

25. So What Does A Sign? A clearly must provide proof he owns the prefix
He also must prove he originated the update
And only A can prove that he intended the path to go through B
So he has to sign for all of that

26. Address Attestations in S-BGP
These are used to prove ownership of IP prefix spaces
IP prefix owner provides attestation that a particular AS can originate its BGP updates
That AS includes attestation in updates

27. Route Attestations
To prove that path for a prefix should go through an AS
The previous AS on the path makes this attestation
E.g., B attests that C is the next AS hop

28. How Are These Signatures Done?
Via public key cryptography
Certificates issued by proper authorities
ICANN at the top
Hierarchical below ICANN
Certificates not carried with updates
Otherwise, messages would be too big
Off-line delivery method proposed

29. S-BGP and IPSec S-BGP generates the attestations itself
But it uses IPSec to deliver the BGP messages
Doing so prevents injections of replayed messages
Also helps with some TCP-based attacks
E.g., SYN floods

30. S-BGP Status Not getting traction in networking community
Probably not going to be the ultimate solution
IETF working group is looking at various protocols with similar approaches
BGPsec, for example

31. Other BGP Security Approaches
Filter BGP updates from your neighbors
Don’t accept advertisements for prefixes they don’t own
Requires authoritative knowledge of who owns prefixes
Use Resource PKI to distribute certificates on who owns what prefixes
Sanity check routes
Continuous monitoring of routing system

32. Protecting Other Styles of Protocols
Generally, how do you know you should believe another router?
About distance to some address space
About reachability to some address space
About other characteristics of a path
About what other nodes have told you

33. How Routing Protocols Pass Information
Some protocols pass full information
E.g., BGP
So they can pass signed information
Others pass summary information
E.g., RIP
They use other updates to create new summaries
How can we be sure they did so properly?

34. Who Are You Worried About?
Random attackers?
Generally solvable by encrypting/authenticating routing updates
Misbehaving insiders?
A much harder problem
They’re supposed to make decisions
How do you know they’re lying?

35. A Sample Problem 1 2 3 1 B C D E A H F G How can H tell someone lied?A H
1.2.3.* F G
How can H tell someone lied? 1 2
Assume a distance vector protocol
How can H tell that E lied?

36. Types of Attacks on Distance Vector Routing Protocols
Blackhole attacks
Claim short route to target
Claim longer distance
To avoid traffic going through you
Inject routing loops
Which cause traffic to be dropped
Inject lots of routing updates
Generally for denial of service

37. How To Secure a Distance Vector Protocol?
Can’t just sign the hop count
Not tied to the path
Instead, sign a length and a “second-to-last” router identity
By iterating, you can verify path length

38. An Example B C D E A H
1.2.3.* F G
H needs to build a routing table entry for *
Should show hop count of 3 via G, 5 via E

39. One Way to Do It H directly verifies that it’s one hop to E1 - B C D E D 2 E A H C 3 D F G B 4 C A 5 B
H directly verifies that it’s one hop to E
Now we can trust it’s five hops to A
H gets signed info that D is 2 hops through E
Then we iterate

40. Who Does the Signing? The destination A in the example
It only signs the unchanging part
Not the hop count
But an update eventually reaches H that was signed by A

41. What About That Hop Count?
E could lie about the hop count
But he can’t lie that A is next to B
Nor that B next to C, nor C next to D, nor D next to E
Unless other nodes collude, E can’t claim to be closer to A than he is

42. What If Someone Lies? There’s limited scope for effective lies1 - B C D E D 2 E A H C 3 D F G B 4 C A 5 B
There’s limited scope for effective lies
E can’t claim to be closer to A
Since E can’t produce a routing update signed by A that substantiates that

43. A Difficulty This approach relies on a PKI
H must be able to check the various signatures
Breaks down if someone doesn’t sign
That’s a hole in the network, from the verification point of view
Consider, in example, what happens if C doesn’t sign

44. What If C Doesn’t Sign? E 1 - B C D E D 2 E A H C 3 D F G B 4 C
A message coming through D tells us that it’s three hops to C A 5 B
But how can he be sure D is next to C?
But H can’t verify that
Other than trusting D . . .
H knows C is next to B
And that B is next to A

45. What’s the Problem? For this graph, no problem1 - B C D E D 2 E A H C 3 D F G B 4 C
For this graph, no problem A 5 B
But how about for this one? A B C D E F G H

46. DNS Security
The Domain Name Service (DNS) translates human-readable names to IP addresses
E.g., thesiger.cs.ucla.edu translates to
DNS also provides other similar services
It wasn’t designed with security in mind

47. DNS Threats Threats to name lookup secrecy
Definition of DNS system says this data isn’t secret
Threats to DNS information integrity
Very important, since everything trusts that this translation is correct
Threats to DNS availability
Potential to disrupt Internet service

48. What Could Really Go Wrong?
DNS lookups could be faked
Meaning packets go to the wrong place
The DNS service could be subject to a DoS attack
Or could be used to amplify one
Attackers could “bug” a DNS server to learn what users are looking up

49. Where Does the Threat Occur?
Unlike routing, threat can occur in several places
At DNS servers
But also at DNS clients
Which is almost everyone
Core problem is that DNS responses aren’t authenticated

50. The DNS Lookup Process
lookup thesiger.cs.ucla.edu
answer
ping thesiger.cs.ucla.edu
If the answer is wrong, in standard DNS the client is screwed
Should result in a ping packet being sent to

51. How Did the DNS Server Perform the Lookup?
Leaving aside details, it has a table of translations between names and addresses
It looked up thesiger.cs.ucla.edu in the table
And replied with whatever the address was

52. Where Did That Table Come From?
Ultimately, the table entries are created by those owning the domains
On a good day . . .
And stored at servers that are authoritative for that domain
In this case, the UCLA Computer Science Department DNS server ultimately stored it
Other servers use a hierarchical lookup method to find the translation when needed

53. Doing Hierarchical Translation
DNS root server
Where’s edu?
lookup thesiger.cs.ucla.edu
edu root server
Where’s ucla.edu?
Where’s cs.ucla.edu?
Where’s thesiger.cs.ucla.edu?
ucla.edu root server
cs.ucla.edu root server

54. Where Can This Go Wrong?
Someone can spoof the answer from a DNS server
Relatively easy, since UDP is used
One of the DNS servers can lie
Someone can corrupt the database of one of the DNS servers

55. lookup thesiger.cs.ucla.edu
The Spoofing Problem
lookup thesiger.cs.ucla.edu
answer
Unfortunately, most DNS stub resolvers will take the first answer
answer

56. lookup thesiger.cs.ucla.edu
DNS Servers Lying
answer
lookup thesiger.cs.ucla.edu
. . .
thesiger.cs.ucla.edu
That wasn’t very nice of him!

57. DNS Database Corruption
answer
lookup thesiger.cs.ucla.edu
. . .
thesiger.cs.ucla.edu

58. The DNSSEC Solution Sign the translations Who does the signing?
The server doing the response?
Or the server that “owns” the namespace in question?
DNSSEC uses the latter solution

59. Implications of the DNSSEC Solution
DNS databases must store signatures of resource records
There must be a way of checking the signatures
The protocol must allow signatures to be returned

60. Checking the Signature
Basically, use certificates to validate public keys for namespaces
Who signs the certificates?
The entity controlling the higher level namespace
This implies a hierarchical solution

61. The DNSSEC Signing Hierarchy
In principle, ICANN signs for itself and for top level domains (TLDs)
Like .com, .edu, country codes, etc.
Each TLD signs for domains under it
Those domains sign for domains below them
And so on down

62. An Example
Who signs the translation for thesiger.cs.ucla.edu to ?
The UCLA CS DNS server
How does someone know that’s the right server to sign?
Because the UCLA server says so
Securely, with signatures
The edu server verifies the UCLA server’s signature
Ultimately, hierarchical signatures leading up to ICANN’s attestation of who controls the edu namespace
Where do you keep that information?
In DNS databases

63. Using DNSSEC To be really secure, you must check signatures yourself
Next best is to have a really trusted authority check the signatures
And to have secure, authenticated communications between trusted authority and you

64. A Major Issue
When you look up something like cs.ucla.edu, you get back a signed record
What if you look up a name that doesn’t exist?
How can you get a signed record for every possible non-existent name?

65. The DNSSEC Solution Names are alphabetically orderable
Between any two names that exist, there are a bunch of names that don’t
Sign the whole range of non-existent names
If someone looks one up, give them the range signature

66. For Example, > host last.cs.ucla.edu
lasr.cs.ucla.edu
You get authoritative information that the name isn’t assigned
lbsr.cs.ucla.edu –
pd.cs.ucla.edu
NOT ASSIGNED
pelican.cs.ucla.edu
toucan.cs.ucla.edu
pelican.cs.ucla.edu
toucan.cs.ucla.edu
Foils spoofing attacks
> host last.cs.ucla.edu

67. Status of DNSSEC Working implementations available
In use in some places
Heavily promoted
First by DARPA
Now by DHS
Beginning to get out there

68. Status of DNSSEC Deployment
ICANN has signed the root
1385 TLDs have signed
Including .com, .gov, .edu, .org, .net
Not everyone below has signed, though
Many “islands” of DNSSEC signatures
Signing for themselves and those below them
In most cases, just for themselves
Utility depends on end machines checking signatures

69. Using DNSSEC
Actually installing and using DNSSEC not quite as easy as it sounds
Lots of complexities down in the weeds
Particularly hard for domains with lots of churn in their namespace
Every new name requires big changes to what gets signed

70. Other DNS Security Solutions
Encrypt communications with DNS servers
Prevents DNS cache poisoning
But assumes that DNS server already has right record
Ask multiple servers
Majority rules or require consensus

71. Conclusion Correct Internet behavior depends on a few key technologies
Especially routing and DNS
Initial (still popular) implementations of those technologies are not secure
Work is ongoing on improving their security