Access Network Solutions

MATMUNI – MAC Address Translation, Traffic Manager, MPLS-UNI

2

Outline

1. Internet Growth2. General Impacts3. Relevance for Access Networks4. The Solution MATMUNI5. Example Scenarios6. Summary

7. Appendix

3

Internet Growth

• Increasing User Numbers

4

Internet Growth

• Increasing User Numbers• New Technologies (xDSLs, Cable, Fiber…)

10m 100m 10km1km

10Mb/s

100Mb/s

1Gb/s

Dat

a ra

te

Distance from/to CPE

1Mb/s

FTTH: EPON, GPON

FTTC/B: FLC, EPON, GPON100Mb/s: VDSL2

FTTN: FLC, EPON, GPON20Mb/s:VDSL2, ADSL2+

10Mb/s: VDSL, ADSL2

1Mb/s: ADSL

TriplePlayService

HighSpeedInternet

copper

optical fiber

5

Internet Growth

• Increasing User Numbers• New Technologies (xDSLs, Cable, Fiber…)• New fancy Services (triple-, quadruple-, …, n-tuple-Play)

6

Internet Growth

• Increasing User Numbers• New Technologies (xDSLs, Cable, Fiber…)• New fancy Services (triple-, quadruple-, …, n-tuple-Play)

Radical Change of Audience(compared to, e.g., 1980)

Internet = MASS-Medium!Critical Impacts

7

General Impacts

• Traffic Load/Volume increasesTraffic Management needed

• QoS Demands & Workload increaseHigh-performance / Non-blocking Operation neededManageable Solutions for Traffic Differentiation needed

• Security decreases (Anonymity, typical Attack Scenarios)Need for Prevention of Attack Scenarios

• Complexity increases (many Users & Addresses)Scale Address SpaceFast Routing

8

Relevance for Access Networks

• What can Access Networks do about this?– Aggregation – Authorization & Authentication– Preprocess Traffic in Front of Core Networks

• Preprocessing Options– Metering, Policing, Shaping– Enforce Limits (e.g., number of MACs per port)– Enforce Identity & Uniqueness (e.g., MAT in L2 networks)– Inspect and apply Policy to prevent certain Attacks

• But keep it all transparent to End Points!

This is what MATMUNI is about!

9

The Solution - MATMUNI

• Where to place MATMUNI?– Logically between DSLAM and BRAS– Physically on DSLAM

up to 4 x GEbi-directional

channels

10

MATMUNI – Building Blocks

MAC Address Translation• Mapping of Customer

MACs to Provider MACs• 1:1 = Security• n:1 = Scalability• Extra Options:

– Bypass– Discard– ARP Handling– DHCP Handling– Configurable partial

Translation1:1... ...

11

Traffic Manager• Metering, Policing

Colormarking,• Already in Access Area

• Different Versions:– MPLS Experimental Bits– IP DSCP-Field

MATMUNI – Building Blocks

-40

60

160

260

360

460

0 50 100 150 200 250 300

Time [ms]

Cou

nter

Val

ues

CIR-Counter BIR-Counter CIR BIR

Upstream

Lookup Logic &Color Information Tables

MPLS Layer 2 Header

Frame & Data

MPLS Layer 2 Header

MPLS Label

Frame & Data

MPLS Label

End of Label Stack

TTL (derived from IP)

End of Label Stack

TTL (derived from IP)

Key &no. of Bytes

Color Information

MPLS Label Stack

Experimental Bits Frame Color

12

MATMUNI – Building Blocks

MPLS-User Network Interface• Encapsulation Scheme• Meant for fast Routing

Here: Simply a Containerto carry Information

• Martini Encapsulation• Not a full-blown LER

13

MATMUNI Characteristics

Major Characteristics• Flexible Layer 2 Address Translation• Traffic Management • MPLS-User-Network-Interface

Other Characteristics• Standards Compliance (Translation, no Encapsulation)• Transparency for User Traffic (IP)• Modular System Architecture (extensible, configurable)• Total Throughput only limited by Hardware Constraints• MPLS Labels = Generic Information Container• Structured PMACs embed Hierarchy of Access Network

14

4. MATMUNI – Prototype

• “It really works!”• Xilinx Virtex-4 FX20 Eval-Board with 1x GE bi-directional

Channel• GUI for Configuration & Monitoring

15

Now How Does MATMUNI Work?

Examples.

16

ARP Cache Alice

IP MAC

IP(GW) MAC(GW)

IP(x) MAC(x)

IP(y) MAC(y)

Problem: ARP Spoofing

• Before attack: Eve receives no non-owned frames

ARP Cache Gateway

IP MAC

IP(Alice) MAC(Alice)

IP(x) MAC(x)

IP(y) MAC(y)

SimplifiedScenario!

17

ARP Cache Alice

IP MAC

IP(GW) MAC(GW)

IP(x) MAC(x)

IP(y) MAC(y)

• 1st step: Poison Alice’s ARP CacheIP(Gateway) == MAC(Eve)Alice’s frames go through Eve to Gateway

Problem: ARP Spoofing

ARP Cache Gateway

IP MAC

IP(Alice) MAC(Alice)

IP(x) MAC(x)

IP(y) MAC(y)

ARP Cache Alice

IP MAC

IP(GW) MAC(Eve)

IP(x) MAC(x)

IP(y) MAC(y)

ARP Spoofing: Alice

IP: GW M

AC: Eve

SimplifiedScenario!

18

ARP Cache Gateway

IP MAC

IP(Alice) MAC(Alice)

IP(x) MAC(x)

IP(y) MAC(y)

Problem: ARP Spoofing

• 2nd step: Poison Gateway’s ARP CacheIP(Alice) == MAC(Eve)All frames from Alice & Gateway go through Eve

ARP Cache Alice

IP MAC

IP(GW) MAC(Eve)

IP(x) MAC(x)

IP(y) MAC(y)

ARP Spoofing: Alice

IP: GW M

AC: Eve

ARP Spoofing: Gateway

IP: Alice MAC: Eve

ARP Cache Gateway

IP MAC

IP(Alice) MAC(Eve)

IP(x) MAC(x)

IP(y) MAC(y)

Reason:Automatic/dynamicupdate of ARP tables

solved by MAT on next slide

SimplifiedScenario!

19

ARP Spoofing Prevention with MAT

• MAT’s FDB is not automatically updated by ARP• Manipulated ARP frames will be dropped

The Clients’ and GW’s ARP caches are not poisoned

Gateway GW

IP MAC

IP(GW) MAC(GW)

ARP Cache Gateway(auto update)

IP MAC

IP(Alice) PMAC(Alice)

IP(X) PMAC(X)

IP(Eve) PMAC(Eve)

MAT Mapping Table (static)

CMACs PMACs

MAC(Alice) PMAC(Alice)

MAC(X) PMAC(X)

MAC(Eve) PMAC(Eve)

Internet &Services

Eve

Client X

Alice

ARP Cache Clients(auto update)

L2-Devicewith MAT

Mechanism

Port

1

2

3

1

2

3

SimplifiedScenario!

20

• Congestions and runaway Frame Drops withoutLimitations through Traffic Manager

• Hard Limit @ 100% Bandwidth (BW) UtilizationWho follows or relies on „Fair Use Policies“when subscribing for Internet Access?

Problem: Oversubscribtion & Congestion

0

20

40

60

80

100

120

DCBA

Peaks over 100% would be discarded

potentially unfair

Possible BW Limitation set by TM (e.g., 20%

BW Utilization allowedper Users)

Maximum BW (100%)

Bandwidth Demands for 4 Users (simplified)

21

Fair Bandwidth Utilization with TM

• With TM, Limitation of each Users Traffic Load to thesubscribed and configured Value (20% in the Example)

• Still extra BW available for other Services• Fair

0

20

40

60

80

100

120

DCBA

Possible BW Limitation set by TM (e.g., 20%

BW Utilization allowedper Users)

Maximum BW (100%)

Bandwidth Demands for 4 Users (simplified)

Policing & Frame Drops on a per-Customer Basis

22

Summary

1:1... ...

• n:1 MAT• Reduce FDB Size

• 1:1 MAT• Identity (Translation

Scheme)• Attack Prevention

• Traffic Manager• Fair Bandwidth Allocation & QoS

• Expand MPLS into Access Area• Generic Information Container

• FPGA Hardware Solution (wire speed)• Flexibility by Reconfiguration

23

Results are internationally accepted!

“sMAT – A Simplified MAC Address Translation Scheme“15th IEEE Workshop on Local and Metropolitan Area Networks, 2007, Princeton, NJ, USA

“Configuration Tool and FPGA-Prototype of a Hardware Packet Processing System“Design, Automation and Test in Europe Conference and Exhibition, 2007, Nice, France

“An integrated Hardware Solution for MAT, MPLS-UNI, and TM in Access Networks“31st Annual IEEE Conference on Local Computer Networks, 2006, Tampa, FL, USA

“Wirespeed MAC Address Translation and Traffic Management in Access Networks“World Telecommunications Congress 2006, Budapest, Hungary,

“A Simplified, Cost-Effective MPLS Labeling Architecture for Access Networks“World Telecommunications Congress 2006, Budapest, Hungary

Thomas Bahls, Stephan Kubisch, Daniel Duchow, Harald Widiger

24

Appendix(Technical Information)

25

System Architecture

• 2-8 main GbE Data Paths• Vertical Control Paths for Memory Operations (on- or

offboard) and System Configuration (CPU)• Serially linked functional Modules

26

Synthesis Results

• Xilinx Virtex 4 FX20-11 FPGA, ISE XST Synthesis Flow• min = minimal Key configured• max = all possible Keys configured• 125 MHz required for non-blocking GbE Operation

2x210220MAT (UP & Downstram)

2x240190TM (UP & Downstream)

205180Framebuffer

336/723150Key Parser & Framebuffer

640160CPU Arbiter

282/1023160Memory Arbiter

101320MPLS-Delabeler

129180MPLS-Labeler

2300/4300140MATMUNI Core System

Slices min/maxSpeed in MHzHardware Module

27

Simulation Results

Drop Rate vs. Framesize and Number of Table Entries

0,00

0,10

0,20

0,30

0,40

0,50

0,60

0,70

60 110 160 210 260

Framesize [Bytes]

Dro

p R

ate

[%]

1024 2048 4096

• 8 independent GbEchannels

• Artificial traffic– only minimal frames

• Realistic traffic– 35 % minimal– 11 % average– 10 % maximal – 44 % random

no packet losses• Average latency 130

cycles (≈1 us for GbE)