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?