1. Stein-64 Slide 1 PW security requirements PWE3 – 64 th IETF 10 November 2005 Yaakov (J) Stein

2. Stein-64 Slide 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. Stein-64 Slide 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. Stein-64 Slide 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. Stein-64 Slide 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 doesn’t 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. Stein-64 Slide 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 can’t insert a packet with proper format from outside SP network MPLS label S=0 PW label S=1 0000 control word L2TPv3 without cookies can have valid format packets inserted

7. Stein-64 Slide 7 PW man-in-the-middle 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 S-PE PE P PWE control PWE control protocol

8. Stein-64 Slide 8 Another scenario 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 PE P

9. Stein-64 Slide 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 can’t encrypt PW label (not legal MPLS) shouldn’t 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. Stein-64 Slide 10 VCCV extensions PWE3 – 64 th IETF 10 November 2005 Yaakov (J) Stein

11. Stein-64 Slide 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. Stein-64 Slide 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. Stein-64 Slide 13 PW Performance OAM format 0001 0000 00000000 associated channel type type code service specific info PWACHVERSIONRESERVEDneed IANA allocation timestamps

14. Stein-64 Slide 14 Open questions what should the time format be? RTP style – 32 bit based on N*8KHz 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  t 4 – for ICMP-like timestamps many – for IEEE 1588-like timestamps what about loop-back requests?