1 / 14

PW security requirements

PW security requirements. PWE3 – 64 th IETF 10 November 2005. Yaakov (J) Stein. 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

orrick
Download Presentation

PW security requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  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. 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 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 D t • 4 – for ICMP-like timestamps • many – for IEEE 1588-like timestamps what about loop-back requests?

More Related