1 / 8

Packet Timing Security Aspects TICTOC – IETF 78

Packet Timing Security Aspects TICTOC – IETF 78. Stefano Ruffini, Ericsson. Introduction. Aspects related to security planned to be studied in TICTOC Relevant discussions in earlier meetings , e.g.:

gay
Download Presentation

Packet Timing Security Aspects TICTOC – IETF 78

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. Packet Timing Security AspectsTICTOC – IETF 78 Stefano Ruffini, Ericsson

  2. Introduction • Aspects related to security planned to be studied in TICTOC • Relevant discussions in earlier meetings , e.g.: • Security aspects in Femtocell application (Tictoc-1 from IETF-75: http://www.ietf.org/proceedings/75/slides/tictoc-1) • Problem Statement Security (tictoc-2 from IETF -77: http://www.ietf.org/proceedings/77/slides/tictoc-2/tictoc-2_files/frame.htm ) • Note: ITU-T G.8265 provides general considerations on this subject. Work in TICTOC may provide valuable complement • Some considerations are presented in the following slides indicating aspects that could be considered

  3. Security and Timing • For packet-based synchronization (PTP or NTP) the protection of the timing data being delivered is a crucial feature • to prevent malicious attacks, • to avoid accidental disturbances • Timing packets could be intercepted by other than the intended recipient, remanufactured in various ways and replayed in whole or part. • An intruder could inject false time values, disrupt the protocol or congest the network • Timing data need to come from a trusted source of synchronization, • loss, manipulation or corruption of data must be prevented or detected • Availability, integrity and authentication need to be put in place, • Confidentiality may not be essential in this respect • Nevertheless, It is important to permit the operation with existing, standards-based security techniques. • Aspects highlighted by G.8265: • slaves should be prevented from connecting to rogue masters; masters should be prevented from providing service to unauthorised slaves • It may not be possible to implement some of these (security) requirements without actually degrading the overall level of timing or system performance.

  4. Operator’s core network UE HNB unsecure link SeGW HNB GW OAM OAM Mobile Backhaul • Mobile Backhaul normally is a closed network but exceptions exist (e.g. femtocell); • In case of a closed network only insiders, i.e., people who have direct access to the Mobile Backhaul network can initiate attacks. • IPSEC is being considered in some mobile applications, especially in case of « unsecure links » being involved (e.g. femtocells, see 3GPP TR 22.820) • IPSEC can provide: authentication, confidentiality, integrity • Note: some Man–in-the-Middle attacks may not be handled by IPSEC (e.g. ARP spoofing creating additional delays) and shall be specifically addressed

  5. Handling of Timing packets and IPSEC • 1588 Transparent Clock • Payload is modified as to add information on the actual delays • not feasible in case of encrypted data (e.g. IPSEC) • some issues also in case of multioperator • Ongoing discussions on Layer violation issues • 1588 Boundary Clock (or Stratum Clock in case of NTP) • Timing packets are terminated and regenerated • Additional delay variation in case of IPSEC (performance issues) • Not viable for trasparent timing transport • Controlling the delay • Data is not modified • Might be the only solution in case of IPSEC (no need to modify the payload) • Need to identify the PTP packet Example in case of VDSL or GPON (see C977 from SG15 – June 2010)

  6. Identifying PTP (or NTP) packets in IPSEC • It may be advantageous to identify if the content of a tunnel are “special” packets from a timing perspective (e.g. PTP/NTP) • This may allow a specific handling of the packet • Additional issues when the content of the timing packet is encrypted (e.g. IPSEC); • How to identify Timing packets in case of IPSEC: • IPSEC Header (e.g. RES bits) • “unused” QoS bits in the IP header • Others • Discussions with concerned group is necessary (e.g. ipsecme)

  7. NTP and PTP Security Schemes • NTP and PTP can provide protocol level security • IEEE 1588 Experimental Annex K provides group source authentication, message integrity, and replay attack protection • NTP v4 Autokey protocol defines a security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography) (Note: “Its design is based on the premise that this IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy”.) • Further investigation required to better understand the applicability and need for these features in a mobile backhaul environment

  8. Conclusions • Security is a key aspect in case of packet timing. • Several aspects need to be investigated, e.g.: • Applicability and need of the protocols security features (NTP Autokey, PTP Annex K) in mobile backhaul • Timing packets over IPSEC • Scenarios • Performances • Identification of Timing Packets

More Related