A Secure and Scalable Internet Routing Architecture (SIRA)

A Secure and Scalable Internet Routing Architecture (SIRA) Motivation

 Customer Networks, who act as source or sink for data packets, behave differently and have different needs from Provider Networks, whose primary role is to provide data transit service for customers.

3

Daniel Massey

Colorado State University [email protected]

Beichuan Zhang

University of Arizona [email protected]

Colorado State University [email protected]

Ricardo Oliveira Lixia Zhang

UCLA {rveloso,lixia}@cs.ucla.edu

More customers than providers

R2

 Customers and providers have different vulnerabilities and advantages with respect to scalability, security and traffic engineering.

Customer links also growing: mostly due to multi-homing practices

TE Customer networks see GTN as one giant node, so two customers can negotiate policies without involving providers

 A flap at customer network triggers several routing updates in the core.

Traffic Engineering  Multi-homed customers would like to control how traffic enters and leaves the their network.  Providers have traffic engineering requirements and may be better suited to make routing decisions.  Current network is a compromise between provider and customer objectives, resulting in conflicts and complexity.

C2

E

F

R7 R6 A B C D E F G H

scale Routing tables at customer routers cover local routes and routes to immediate neighbors (s.a. GTN edge routers)

R7

Customers and providers have different address spaces

B D

20% on D

C2

 Need to tell Src

IBM Customer Multihoming

CSU Los Nettos

LA

NY

ATT Denver

security Attacks originating from customers (s.a. botnets) cannot target core routers

C3

C4

S

TE Customer policies simple to express, involve three hops: 1. An outgoing hop to reach other customers 2. A GTN hop, and 3. A destination customer

London

Provider interconnect

UUNET Miami

R3

R2

80% traffic on C

• Ex: Link between R2, C2 may be down

Or, global scope (i.e., span multiple geographic locations)

Seattle

X

C5

• How to convey this to sender?

A Possible New Address Structure

A

R6

RIB at C1 C2 C1 C3 C4 C5 R1

• Links between CN and PN may change state (up/down, congestion etc)

Organizations have local scope (i.e. specific to a geographic location)

Global Transit Network (GTN)

C scale Route flaps at the edge (customer nets) do not generate updates in core routing

4

H

R1

Mapping is also a convenient place for expressing routing policies

Mapping service gives GTN exit router(s) needed to reach some destination customer network

• Performance improvements: caching, prefetching?

R5

R8

Customer T

• Hierarchy (s.a. DNS) or DHT-based?

60% on H

G

Dst

Customer S

• Security of mapping service.

C7

40% on G

RIB at R8

Routing Scalability

 Local routing changes propagate globally.

R2

R3

Dst X Src A

• How to express routing policies?

C6

R4

 Malicious prefix hijacking attacks.

 Traffic engineering and multi-homing practices further increases customer growth.

1

Challenges for Mapping and Border Links

T scale Routing tables at provider routers cover local routes and routes to other providers within GTN

 Customer networks directly influence routing in the core.

 Providers grow slowly compared to customers.

X CPEM

Y

Src

Why Separate?

 Besides, end systems have no reason to contact core routers!

 Customer networks and provider networks scale differently.

R1 Dst X Src A

CPB

Provider growth much slower than customer growth

Routing Infrastructure Security

 Mis-configuration errors.

R2

Forwarding plane separation: encapsulate customer packets in provider packets

Dst X Src A

Routing Problems Addressed by SIRA

 Thousands of low security end systems can target core routers (a.k.a., botnet attacks).

AT&T Research [email protected]

C1

 Packets originating from customers cannot be addressed to provider devices.

 Customer systems can directly address core routers.

Dan Pei

2 B

R1

 Customers have routes to only local subnets, direct providers, and directly connected customers.

2

3

R1 Dst X Src A

A

 These problems may be simplified if customers and providers are de-coupled into separate routing, forwarding and address spaces

 Providers have routes to only other providers and directly connected customers.

University of Memphis [email protected]

Links between customers and providers may fail: handled by explicit notifications Global Transit Network

Small number of providers but more interconnects; more options for traffic control

customers grow faster

Lan Wang

How SIRA Separates Customers and Providers

Separating Customers from Providers

Address Space

1

Vamsi Kambhampati

Sydney

Metro Locations

Metro-based routing improves hot-potato routing

Interconnect link not owned by UUNET or ATT

SIRA Address Structure Inspired by Previous Proposals O OL OL Organization L Location S S Subnet I I SI Interface OL OS LS

- Organization-specific Location - Organization-specific Subnet - Location-specific Subnet

OI LI SI

- Organization-specific Interface - Location-specific Interface - Subnet-specific Interface

1. Steve Deering. Metro-based Addressing: A Proposed Addressing Scheme for IPv6 Internet. Presentation, Xerox PARC, July 1995. 2. Steve Deering. The Map & Encap Scheme for Scalable IPv4 Routing with Portable Site Prefixes. Presentation, Xerox PARC, March 1996. 3. Mike O’Dell. GSE - An Alternate Addressing Architecture for IPv6. draft-ietf-ipngwg-gseaddr00.txt, February 1997.