Tag

Data integrity

Browsing


In today’s world, where digital information rules, keeping networks secure is not just important—it’s essential for the smooth operation of all our communication systems. Optical Transport Networking (OTN), which follows rules set by standards like ITU-T G.709 and ITU-T G.709.1, is leading the charge in making sure data gets where it’s going safely. This guide takes you through the essentials of OTN secure transport, highlighting how encryption and authentication are key to protecting sensitive data as it moves across networks.

The Introduction of OTN Security

Layer 1 encryption, or OTN security (OTNsec), is not just a feature—it’s a fundamental aspect that ensures the safety of data as it traverses the complex web of modern networks. Recognized as a market imperative, OTNsec provides encryption at the physical layer, thwarting various threats such as control management breaches, denial of service attacks, and unauthorized access.

OTNsec

Conceptualizing Secure Transport

OTN secure transport can be visualized through two conceptual approaches. The first, and the primary focus of this guide, involves the service requestor deploying endpoints within its domain to interface with an untrusted domain. The second approach sees the service provider offering security endpoints and control over security parameters, including key management and agreement, to the service requestor.

OTN Security Applications

As network operators and service providers grapple with the need for data confidentiality and authenticity, OTN emerges as a robust solution. From client end-to-end security to service provider path end-to-end security, OTN’s applications are diverse.

Client End-to-End Security

This suite of applications ensures that the operator’s OTN network remains oblivious to the client layer security, which is managed entirely within the customer’s domain. Technologies such as MACsec [IEEE 802.1AE] for Ethernet clients provide encryption and authentication at the client level.Following are some of the scenerios.

Client end-to-end security (with CPE)

Client end-to-end security (without CPE)
DC, content or mobile service provider client end-to-end security

Service Provider CPE End-to-End Security

Service providers can offer security within the OTN service of the operator’s network. This scenario sees the service provider managing key agreements, with the UNI access link being the only unprotected element, albeit within the trusted customer premises.

OTNsec

Service provider CPE end-to-end security

OTN Link/Span Security

Operators can fortify their network infrastructure using encryption and authentication on a per-span basis. This is particularly critical when the links interconnect various OTN network elements within the same administrative domain.

OTN link/span security
OTN link/span security

OTN link/span leased fibre security
OTN link/span leased fibre security

Second Operator and Access Link Security

When services traverse the networks of multiple operators, securing each link becomes paramount. Whether through client access link security or OTN service provider access link security, OTN facilitates a protected handoff between customer premises and the operator.

OTN leased service security
OTN leased service security

Multi-Layered Security in OTN

OTN’s versatility allows for multi-layered security, combining protocols that offer different characteristics and serve complementary functions. From end-to-end encryption at the client layer to additional encryption at the ODU layer, OTN accommodates various security needs without compromising on performance.

OTN end-to-end security (with CPE)
OTN end-to-end security (with CPE)

Final Observations

OTN security applications must ensure transparency across network elements not participating as security endpoints. Support for multiple levels of ODUj to ODUk schemes, interoperable cipher suite types for PHY level security, and the ability to handle subnetworks and TCMs are all integral to OTN’s security paradigm.

Layered security example
Layered security example

This blog provides a detailed exploration of OTN secure transport, encapsulating the strategic implementation of security measures in optical networks. It underscores the importance of encryption and authentication in maintaining data integrity and confidentiality, positioning OTN as a critical component in the infrastructure of secure communication networks.

By adhering to these security best practices, network operators can not only safeguard their data but also enhance the overall trust in their communication systems, paving the way for a secure and reliable digital future.

References

More Detail article can be read on ITU-T at

https://www.itu.int/rec/T-REC-G.Sup76/en

The ITU standards define a “suspect internal flag” which should indicate if the data contained within a register is ‘suspect’ (conditions defined in Q.822). This is more frequently referred to as the IDF (Invalid Data Flag).

PM is bounded by strict data collection  rules as defined in standards. When the collection of PM parameters is affected then  PM system labels the collection of data as suspect with an Invalid Data Flag (IDF). For the sake of identification; some unique flag  is shown next to corresponding counter.

The purpose of the flag is to indicate when the data in the PM bin may not be complete or may have been affected such that the data is not completely reliable. The IDF does not mean the software is contingent.

Some of the common reasons  for setting the IDF include:

  • a collection time period that does not start within +/- 1 second of the nominal collection window start time.
  • a time interval that is inaccurate by +/- 10 seconds (or more)
  • the current time period changes by +/- 10 seconds (or more)
  • a restart (System Controller restarts will wipe out all history data and cause time fluctuations at line/client module;  a module restart will wipe out the current counts)
  • a PM bin is cleared manually
  • a hardware failure prevents PM from properly collecting a full period of PM data (PM clock failure)
  • a protection switch has caused a change of payload on a protection channel.
  • a payload reconfiguration has occurred (similar to above but not restricted to protection switches).
  • an System Controller archive failure has occurred, preventing history data from being collected from the line/client  cards
  • protection mode is switched from non-revertive to revertive (affects PSD only)
  • a protection switch clear indication is received when no raise was indicated
  • laser device failure (affects physical PMs)
  • loss of signal (affects receive – OPRx, IQ – physical PMs only)
  • Control Plane is booted less than 15 min period for 15-min interval and less than 24 hour period for 24-hour interval.

Suspect interval is determined by comparing nSamples to nTotalSamples on a counter PM. If nSamples is not equal to nTotalSamples then this period can be marked as suspect. 

If any 15 minute is marked as suspect or reporting for that day interval is not started at midnight then it should flag that 24 Hr as suspect.

Some of the common examples are:

  • Interface type is changed to another compatible interface (10G SR interface replaced by 10G DWDM interface),
  • Line type is changed from SONET to SDH,
  • Equipment failures are detected and those failures inhibit the accumulation of PM.
  • Transitions to/from the ‘locked’ state.
  • The System shall mark a given accumulation period invalid when the facility object is created or deleted during the interval.
  • Node time is changed.