Transcript 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.:
– 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
© Ericsson AB 2010
2
2010-07-22
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, standardsbased 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.
© Ericsson AB 2010
3
2010-07-22
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)
Operator’s core
network
UE
HNB
unsecure
link
SeGW
OAM
HNB GW
OAM
› 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
© Ericsson AB 2010
4
2010-07-22
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
Correction delay
PTP Flow
PTP Flows
Example in case of VDSL or GPON
OLT/VTU-O
End User
(e.g. Base Station)
ONU/VTU-R
(see C977 from SG15 – June 2010)
G.984.3 Amd. 2
Delay and HW timestamping
© Ericsson AB 2010
5
TBD (VDSL2)
Delay and HW timestamping
2010-07-22
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)
© Ericsson AB 2010
6
2010-07-22
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
© Ericsson AB 2010
7
2010-07-22
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
© Ericsson AB 2010
8
2010-07-22