packet timing security aspects tictoc – ietf 78

Packet Timing Security Aspects TICTOC – IETF 78

Stefano Ruffini, Ericsson

Slide title 32 pt

Text 24 pt

Bullets level 2-520 pt

›!"# $%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~¡¢£¤¥¦§¨©ª«¬®¯°±²³´¶·¸¹º»¼½ÀÁÂÃÄÅÆÇÈËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿĀāĂăąĆćĊċČĎďĐđĒĖėĘęĚěĞğĠġĢģĪīĮįİıĶķĹĺĻļĽľŁłŃńŅņŇňŌŐőŒœŔŕŖŗŘřŚśŞşŠšŢţŤťŪūŮůŰűŲųŴŵŶŷŸŹźŻżŽžƒȘșˆˇ˘˙˚˛˜˝ẀẁẃẄẅỲỳ–—‘’‚“”„†‡•…‰‹›⁄€™−≤≥fifl

Do not add objects or text in

the footer area © Ericsson AB 2010 2010-07-222

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

Slide title 32 pt

Text 24 pt





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.

Slide title 32 pt

Text 24 pt





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

UE HNB SeGWunsecure link

Operator’s core network

HNB GW

OAMOAM

Slide title 32 pt

Text 24 pt





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

ONU/VTU-R

PTP Flows

OLT/VTU-O

End User(e.g. Base Station)

PTP Flow

Delay and HW timestamping

G.984.3 Amd. 2

TBD (VDSL2) Delay and HW timestamping

Correction delay

ONU/VTU-R

PTP Flows

OLT/VTU-O

End User(e.g. Base Station)

PTP Flow

Delay and HW timestamping

G.984.3 Amd. 2

TBD (VDSL2) Delay and HW timestamping

Correction delay

Example in case of VDSL or GPON

(see C977 from SG15 – June 2010)

Slide title 32 pt

Text 24 pt





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)

Slide title 32 pt

Text 24 pt





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

Slide title 32 pt

Text 24 pt





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

packet timing security aspects tictoc – ietf 78

Documents