A Pluralist Approach to Interdomain Communication Security

1
A Pluralist Approach to Interdomain
Communication Security

• Ioannis Avramopoulos
• Princeton University
• Joint work with Jennifer Rexford

2
Economics the Internet Inertness

• Internet infrastructure is insecure
• Despite the obvious threat, countermeasures are
  not being deployed
• E.g., Secure-BGP
• We argue that the reason is mainly economic
• Autonomous systems (ASes) in commercial Internet
  are independent, rational, and pay-off maximizing
  entities

3
Overview

• Economic Case for Pluralism
• Architectural Framework for Pluralism
• Example of Using the Architectural Framework

4
Background Economics of Groups and Goods

• Good Secure communication between domains
• Goods are confidentiality, integrity, and
  availability
• Producing such goods requires action in groups
• Group members are ASes
• Goods can be
• purely public (e.g., public television
  broadcasting)
• purely private (e.g., recorded music sold in
  stores)
• impurely public (e.g., cable television
  broadcasting)
• Type of good can be engineered

5
Background Routing Protocols
6
The Case for Pluralism Purism is not
Economically Viable

• Purism Ubiquitous deployment of a secure routing
  protocol
• Purism treats secure interdomain communication as
  a pure public good
• Therefore, purism is not economically viable

7
The Case for Pluralism Smaller Groups are More
Effective

• Olson classifies interaction among group members
  in three categories
• Large group good will not be provided unless
  there is coercion
• Small group good may be provided by unilateral
  action
• Medium group good may be provided by strategic
  interaction

8
The Case for Pluralism Custom Security Solutions
Per Group

• Many options (mechanisms) to improve
  communication security
• E.g., confidentiality can be protected by a
  secure routing protocol or encryption ciphers
• No single mechanism can address the full gamut of
  threats
• E.g., during a DoS attack you prefer
  unreachability
• Network architecture should support the graceful
  coexistence of different mechanisms

9
SBone Architectural Framework for Pluralism

• Objective support the formation of groups of any
  size---irrespective of IP connectivity of group
  members---without compromising security

10
Formation of Arbitrary Groups Irrespective of IP
Connectivity
island
Archipelago
11
Threat Model

• DoS attacks
• against targets inside the overlay
• against virtual links
• Routing-protocol attacks
• to intercept cross-island traffic
• Data-plane attacks
• to manipulate cross-island traffic

12
Secure Virtual Link Surelink

• Connects a relay point in one island to a relay
  point in another forming an IP tunnel
• Surelinks enhance the service model of a vanilla
  IP tunnel with
• an encryption cipher to protect confidentiality
• an authentication cipher to protect integrity and
  enforce access control
• secure availability monitoring capability

13
Secure Virtual Topology

• Collection of multiple surelinks giving control
  of the underlying paths traffic takes
• Path control can be leveraged to
• proactively prevent routing attacks
• proactively bypass untrusted non-participants
• proactively spread traffic over multiple paths
• reactively reroute traffic to alternate paths

14
Example of Archipelago

• Backbone-provider trusted VPN
• Example of revenue-generating service based on
  coalitions among providers

15
Example of Archipelago
Australian branch
surelinks
Telstra
ATT
US branch
16
Example of Archipelago

• Backbone-provider trusted VPN
• Example of revenue-generating service based on
  coalitions among providers
• Coalition-based trusted VPNs can serve
  multinational customers without additional
  investment on infrastructure

17
Conclusion

• Purism is not economically viable
• Deployment of communication security mechanism
  should be based on pluralism
• I.e., the formation of variable-sized groups
  deploying mechanism customized to group-specific
  needs
• Proposed an architectural framework to support
  pluralism that is backward compatible with
  existing infrastructure

18
Thank you!

• Questions