Stein64 Slide 1 - PowerPoint PPT Presentation
Title: Stein64 Slide 1
1
PWsecurityrequirements
- PWE3 64th IETF
- 10 November 2005
Yaakov (J) Stein
2
the time has come
- the time has come to address PW security
- PWs are being deployed no longer only on paper
- attacks on PWs can impact numerous end-users
- PWs have special features that may be exploited
by hackers
3
Some threats on PWs
- accidental connection to untrusted network,
compromising user traffic - maliciously setting up a PW to gain access to a
customer network - forking of a PW to snoop PW packets
- malicious rerouting of a PW to snoop or modify PW
packets - unauthorized tearing down of a PW
- unauthorized snooping of PW packets
- traffic analysis of PW connectivity
- unauthorized deletion of PW packets
- unauthorized modification of PW packets
- unauthorized insertion of PW packets
- replay of PW packets
- denial of service or significantly impacting PW
service quality
4
Out of scope
- customer networks security
- attachment circuit security
- considerations common to all MPLS networks
- L2TPv3 PWs (should be done in L2TPEXT WG)
- considerations specific to multisegment PWs
5
PW security weaknesses
- PW label is the only identifier in packet
- no verifiable source address, cookies, etc.
- relatively easy to introduce seemingly valid
foreign packets - CW sequence number can be used for DoS attack
- SN processing allows dropping late packets
- so by inserting a future packet, legitimate
packets are lost - even if re-ordering is performed, QoS may be
impacted - PWE control protocol doesnt mandate
authentication - can use LDP-MD5 or secure TCP connection
- should provide ingress filtering on LDP messages
- VPLS, autodiscovery, and MS-PWs all introduce new
problems - will not be treated here
6
PW security strength
- most attacks require compromising PE or P LSRs
- although not necessarily those along PW path
- adequate protection of control plane messaging
can be sufficient - cant insert a packet with proper format from
outside SP network - MPLS label S0
- PW label S1
- 0000 control word
- L2TPv3 without cookies can have valid format
packets inserted
7
PW man-in-the-middle
PE
S-PE
PE
PWE control
PWE control
- impostor causes 2 PWs to be set up, and stitches
them - impostor can snoop, delete, insert, change, etc
packets - Note that this is different from a PSN
man-in-the-middle - where a P LSR is compromised (not handled here)
PE
PE
P
PWE control protocol
8
Another scenario
PE
PE
P
PE
- in this scenario we compromise LSR or L2 not
belonging to PW path - exploit MPLS tunnel merging
- insert packet with PW label associated with PW
being attacked - by judicious use of CW SN we may be able to force
massive packet loss
9
PW packet encryption
- to secure PW traffic from interception we may
encrypt - below PW level (link encryption)
- at PW level (new)
- above PW level (service encryption)
- PW level encryption
- cant encrypt PW label (not legal MPLS)
- shouldnt we encrypt control word
- since lose 0000 and sequence number (see below)
- so how different from service encryption?
- no packet reliability (retransmission) at PW
level - so PW level encryption must work with packet loss
- can rekey based on sequence number
- (can learn from wireless encryption protocols)
10
VCCVextensions
- PWE3 64th IETF
- 10 November 2005
Yaakov (J) Stein
11
2 PW OAM methods
original TDMoIP OAM 1 OAM PW per PSN
tunnel assume defects/performance are the same
for all PWs in tunnel
VCCV style OAM OAM packets in each PW higher
overhead (BW) when there are many PWs in tunnel
12
Performance Measurement
- VCCV presently provides only connectivity
verification - full PW OAM should also provide measurements of
- one way and round trip delay
- PDV ( distribution? spectrum?)
- packet loss ratio
- for TDM PWs it is also useful to
- monitor backup PWs for fast switch-over
- maintain clock synchronization for multiple TDM
PWs - CW format
- use PWACH
13
PW Performance OAM format
PWACH
VERSION
RESERVED
need IANA allocation
0001 0000 00000000 associated
channel type
type code
service specific info
timestamps
14
Open questions
- what should the time format be?
- RTP style 32 bit based on N8KHz
- NTP style seconds expressed as 32 bit integer
32 bit fraction - ICMP style 32 bit milliseconds
- IEEE 1588 style 32 bit seconds 32 bit
nanoseconds - how many timestamps?
- 1 for approximate round-trip
- 2 for approximate one-way
- 3 for round-trip with D t
- 4 for ICMP-like timestamps
- many for IEEE 1588-like timestamps
- what about loop-back requests?
Recommended
CrystalGraphics Presentations
