Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Problem Statement for Securing of Synchronization Networks Greg Dowd Problem Statement for Securing of Synchronization Networks Synchronization for telecoms applications (e.g. sync to wireless basestations, wireline sync replacement, circuit emulation services) is a mission-critical service, in the sense that if the sync goes out of tolerance, the enabled service goes down and impacts revenue. Packet-based synchronization (e.g. PTP or NTP distributed over IP or MPLS networks) therefore requires both security of stream as well as protection of the ephemeral nature of the data being delivered. While this is an example of a synchronization need, it is inevitable that other applications will require the same types of services. The engineering and interoperability of these requirements is within the domain of the ietf and typically not considered by other standards bodies with respect to IP based models. Looking at the requirements for successful synchronization, a number of fundamental considerations are obvious With respect to the stream: 1. 2. 3. Data must come from an unambiguous source. Data may need to come from a trusted source of synchronization. Loss, manipulation or corruption of data must be prevented or detected. With respect to the timing: 1. 2. 3. 4. Data may be lost. Data may be delayed. Data should not be reordered. Data must not be replayed. In the telecom world, various network topologies exist in synchronization schemes: 1. 2. 3. Single network domain Operator network with intervening backhaul provider Unprotected CPE appliance attached to operator network via public domain Internet A variety of options are available to address the requirements for successful synchronization These options can be as simple as network engineering or as complex as ensemble clocks verifying the integrity of the timing data against an alternate signal carried at a different layer of the network. The issues of configuration, management and interoperability of these systems should be addressed by the ietf. While some implementations may be highly customized, many of these are likely to use traditional data integrity and protection schemes. For instance, home femtocells will be connected to the network via IPSec tunnels while operator networks will typically isolate the synchronization networks with VLANs. As these types of operations may have an impact on the quality of the synchronization data, multiple approaches have been put forward to provide optimal solutions. For instance, signaling and management messages might flow over an encrypted IPSec pipe while standard synchronization packets might flow unencrypted. After all, there is little inherent value in a timestamp. How do we determine if this system meets the security requirements of protecting the synchronization flow? What is the impact on other protocols and/or other synchronization flows which may exist in the network? Can the discovery or provisioning of these services be supported, assisted or enhanced by other standard IP protocols such as dhcp? Another approach is to examine the security models provided by the protocols themselves NTP and PTP provide protocol level security to mitigate some of the issues detailed above, however they each have their strengths and weaknesses. For instance, an authentication scheme has been suggested for use in PTP but, as a new protocol, it has had limited security review and the initial data suggests that there are some serious flaws in the initialization of the connections. On the other hand, NTP has a more highly evolved security model, with a layered approach. While this protocol has been subjected to more scrutiny, the sheer variety of trust schema can make the system unwieldy for those unschooled in the protocol. Looking further, the synchronization protocols themselves are inherently resistant to some issues by design. In synchronization systems, each sample input tends to carry little weight so individual data errors, whether malicious or unintentional, can often be rejected. But it is not clear whether the protection provided is sufficient for a particular application framework or is even required. Also, the interaction between these various security models is not clearly understood. The OSI model often has the effect of preventing one layer of the protocol from discovering what security protections are in place at other layers. These issues of configuration, discovery and management of the security framework for synchronization are the type of problem which can be addressed by the ietf and is not currently being addressed in other standards bodies.