Internet-Draft IGP Link/Node Security Advertisement October 2023
Przygienda, et al. Expires 24 April 2024 [Page]
Network Working Group
Intended Status:
A. Przygienda, Ed.
A. Lindem
LabN Networks, L.L.C.
G. Guntanakkala
Juniper Networks

Advertising Link and Node Security Properties in OSPF/IS-IS


This document defines a way for an Open Shortest Path First (OSPF) or IS-IS router to advertise different security states at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular node/link or path meets security policies that have to be enforced. Here, the term "OSPF" means both OSPFv2 and OSPFv3.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 24 April 2024.

Table of Contents

1. Introduction

OSPF/IS-IS, as an IGP, is one of the most critical protocols in a network and compromising integrity of any of its nodes by a misconfiguration or security attack can have catastrophic consequences. Though infrastructure can be deployed to monitor and alarm changes in security status of OSPF nodes it is desirable for a mechanism that allows fastest and completely non-ambiguous detection of any security state change of OSPF nodes or links, independent of, e.g., status of a monitoring connection or implementation defect in any piece of the monitoring infrastructure or ultimately, successful attacks against such infrastructure. The Link State Database (LSDB) is in its nature ideally suited to carry such information given that it is not only a very fast mechanism due to the nature of flooding but also represents the ultimate source of truth in terms of topology state and thus security state.

Security is not a single linear value but is rather most commonly expressed as a triad [CIA] of characteristics that are not necessarily related to each other in a specific technology. Hence we will use the same concept to redistribute a triad of sorted security property vectors for each characteristic (since we want to express strength of a certain technology to ascertain a characteristic unambiguously but we may be still interested whether a certain technology is deployed even if a "stronger" solution is already in place).

2. Glossary

The following terms are used in this document.

Open Shortest Path First
Intermediate System to Intermediate System
Link State Advertisement
Router Information
Node Security Information
Link Security Information
short notion for one of the CIA triad characteristics, i.e., confidentiality, integrity, availability. We will use C for a specific characteristic and |C for the set of all possible C values.
single property of link or node for a C representing something like, .e.g., MACSEC with key-id. We denote a sec-property of a sec-characteristic as p_C and |P_C is the space of all possible p_C values for a C.
sec-property-vector: is an ordered set of p_C \elem_of |P_C. We denote it as v_C. (which implies basically that |P_C must be a total order).
element of |P_C for all C in |C that signifies security property that provides no security aspect. Can be omitted, i.e., is implicit. We will need that to compare sec-property-vectors of different lengths.
sec-property-vector of length 0, i.e., no security property is present. It is implicit for a C in case no v_C is present.
|R_C is the space of all possible v_C. Since p_C is a total order and v_C is an ordered set, |R_C is a total order. We define the ordering relation later in the draft.

3. First Example

Since the definitions are rather plentiful let us provide a first example. Assuming that we distribute for a given node A the following sec-property-vectors:

Table 1: Example Vector for A
C v_C
Confidentiality [ mac-sec ]
Availability [ 10% loss control traffic, 20% loss data traffic ]
Integrity [ 5% ospf rx control traffic corruption, 10% other control traffic corruption, 20% corruption data traffic ]

and in similar fashion for node B:

Table 2: Example Vector for B
C v_C
Confidentiality [ mac-sec, ospf-sha-3 ]
Integrity [ 5% corruption data traffic ]

To disperse a first wrong assumption, we cannot decide which node is "more secure" since overall the security state is not an ordered space, only each of the sec-characteristics is. So we can only compare the sec-property-vectors for each sec-characteristic. Let us do that for each case.

3.1. Confidentiality

Node A advertises "mac-sec" as only sec-property here, while node B advertises "mac-sec" and "ospf-sha-3". Assuming "mac-sec" is a stronger security property than "ospf-sha-3" we can say that node B is more secure since we really compare [ mac-sec, null ] with [ mac-sec, ospf-sha-3 ] and the vectors being ordered the first, "strongest" elements are equal and the second element of the second vector is "stronger" than the second element. While it can be argued that mac-sec makes ospf-sha-3 redundant, we need to define a clear ordering to allow distributed computations and hence node B will be preferred.

3.2. Availability

Node A advertises "10% loss control traffic" and "20% loss data traffic" while node B advertises nothing. Hence for node B the implicit vector [ null, null ] is used and we compare [ 10% loss control traffic, 20% loss data traffic ]. Loss is a "negative" property and hence the lower the value the better. So node B is more secure here.

3.3. Integrity

Node A advertises "5% ospf rx control traffic corruption", "10% other control traffic corruption" and "20% corruption data traffic" as its vector while Node B advertises "5% corruption data traffic" which in reality will be [ null, null, 5% corruption data traffic ] to make the vectors comparable via our definition. Since null is better here than any corruption already the first element tells us that node B is more secure in respect to integrity.

4. Extensible Ordering Relation

To provide a mechanism to compare sec-property to other sec-properties and possibly same sec-property with different values we define an extensible encoding of a sec-property. It will consist basically of the following fields:

Value that identifies the specific property, e.g., ospf sha-2. Contrary to expectations, this is not used except for informational purposes.
this defines the first part of the comparison relation. sec-property with higher strength is considered "stronger" than sec-property with lower strength.
this is a number which defines the second part of the comparison relation, e.g., key length or percentage of corruption/loss. Whether the higher value is better or worse is defined by flags. If a property encompasses multiple function the value has to encoded accordingly, i.e., if the algorithm and the key length are encoded in the same value, the value has to be constructed e.g. in a way that the algorithm is encoded in the higher bits and the key length in the lower bits and the according value is comparable as a integer number.
the function of flags is to allow nodes that do not understand the semantics of the sec-property to still be able to compare it correctly since we cannot exclude that new algorithms or even completely new algorithms will be defined in the future. For the moment the only flag defined is the indication whether the sec-property-attribute is a "negative" property, i.e.. the lower the value the better the property or vice versa or whether it should not be compared at all, i.e., ignored.

This calls for another small example. Let us assume that somebody took a new code point for quantum encryption of a link and the strongest value today is 10. Of course the length of the quantum key plays a role and the longer the key the stronger the resulting security. So the encoding for a node not even aware such a thing exists would be:

[ sec-property-type = ?, sec-property-strength = 11, sec-property-attribute [key length] = 2048, sec-property-flags = higher attribute is better ]

which will allow a node that is not even aware what this sec-property means to compare and tie-break it correctly in a computation.

A problem that remains with the value of the sec-property-attribute in case of implicit null sec-property. Unfortunately we have to assume that a implicit null for a "link loss" represents no losses and is therefore preferable to any loss advertised by other nodes while it may simply mean that the information is not available. This is indicated by one of the flag values that provides information what the value in case of null element should be be.

5. Encodings

5.1. Node Security Information Advertisement for OSPF

The Node Security Information TLV within the body of the OSPF RI Opaque LSA [RFC7770] is used to advertise current node security states.

This TLV is optional and is applicable to both OSPFv2 and OSPFv3. The scope of the advertisement is specific to the deployment.

When multiple Node Security Information TLVs of the same type are received from a given router, the receiver MUST use the first occurrence of the TLV in the Router Information (RI) LSA. If the Node Security Information TLV appears in multiple RI LSAs that have different flooding scopes, the Node Security Information TLV in the RI LSA with the area-scoped flooding scope MUST be used. If the Node Security Information TLV appears in multiple RI LSAs that have the same flooding scope, the Node Security Information TLV in the RI LSA with the numerically smallest Instance ID MUST be used and other instances of the Node Security Information TLV MUST be ignored. The RI LSA can be advertised at any of the defined opaque flooding scopes (link, area, or Autonomous System (AS)). For the purpose of Node Security Information TLV advertisement, area-scoped flooding is RECOMMENDED.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  |    Type                       |  Length                       |
  |  Flags  |  Sec-Type           |           Sec-Strength        |
  |                          Sec-Attribute                        |
  | .. further elements of the vector ..                          |
Figure 1: Node Security Information TLV for OSPF


For OSPFv2, the Node security information is advertised as an optional TLV of the OSPFv2 Router Information LSA as defined in section 2.1 of [RFC7770] and has a type of ?. For OSPFv3, the Node security information is advertised as an optional TLV of the OSPFv3 Router Information LSA as defined in section 2.2 of [RFC7770] and has a type of ?. The type indicates the according security characteristic, i.e., confidentiality, integrity, availability.
variable; same as defined in Section ?.
Vector of ordered sec-property elements.

Format of the vector:

5 bit field that defines the semantics of the sec-property-attribute. The first two bits indicate whether the sec-property-attribute is a "negative" property, i.e., the lower the value the better the property or vice versa or whether the sec-property-attribute should not be compared at all, i.e., ignored and is carried only for information purposes. The third bit when set indicates that for a null element the value of the property should be assumed as maximum (all ones) and when not set as minimum (all zeroes) for comparison purposes. The other bits are reserved and MUST be set to 0 on transmission and ignored on reception.
8 bit field that defines the sec-property-type which is not compared and only carried for information purposes.
8 bit field that defines the sec-property-strength which is compared with higher value indicating a stronger, i.e., "more secure" property.
32 bit field that defines the sec-property-attribute which is compared according to the flags.

This TLV is optional and considered implicit null vector if not present for the according characteristics. The scope of the advertisement is specific to the deployment.

5.2. Node Security Information for IS-IS

The Node Security Information sub-TLV is defined within the body of the IS-IS Router CAPABILITY TLV [RFC7981] to carry the Node security Information available of the router originating the IS-IS Router CAPABILITY TLV.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     |    Type       |   Length      |
     |  Flags  |  Sec-Type           |
     |    Sec-Strength               |
     |      Sec-Attribute            |
     | .. further elements of the vector ..

Figure 2: Node Security Information Sub-TLV


variable; same as defined in Section ?.
equivalent to OSPF with reduced field lenghts.

The Link Security Information sub-TLV is defined to carry the security state of the interface associated with the link and its format is equivalent to Node Security Information Sub-TLV while the security types are reserved from its own registry. The Link Security Information sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and 223 to carry the Link Security Information of the interface associated with the link.

5.4.1. Procedures for Defining and Using Node and Link Security Information Advertisements

When Link Security Information is present for a given Router, the value of the Link Security Information MUST take precedence over the Node security information when considering a link. In case a Link Security_Information-Type is not signaled, but the Node Security_Information-Type is, then the Node Security_Information-Type value MUST be considered to be the Security Information value for that link.

6. Deployment Considerations

Although the advertisements provide a rich model of the current security state of the IGP (and possibly other applications on the node/link) it can be desirable to "squelch" all this information into a single comparable metric for computation purposes. Nothing prevents that.

Given the fact that same sec-property-type can be advertised with different sec-property-strength a node MUST simply ignore such a scenario and use strength only. Obviously, as local policy, such a condition can be flagged and alarmed since it is expected that standardization of new sec-property-type will standardize its strength as well.

Given the flags attached to the same value of sec-property-strength may differ across information provided by multiple nodes, such a condition leads to the vectors being basically incomparable, i.e. a sec-property-type like link loss cannot declare on one node that more loss is better while another node consider less loss better. This scenario leads unavoidably to byzantine security discussion and is kept out of scope of this draft.

7. Applications

One possible, obvious application is to include nodes that meet security criteria in Flex Algorithm [RFC9350] or IP Flex Algorithm [I-D.ietf-lsr-ip-flexalgo] or use the information as a type of single or multi-dimensional metric.

8. IANA Considerations

This document requests allocation for the following code points and registries.


9. Security Considerations

Security concerns for OSPF are addressed in [RFC7474], [RFC4552], and [RFC7166]. Further security analysis for the OSPF protocol is done in [RFC6863]. Security considerations as specified by [RFC7770], [RFC7684], and [RFC8362] are applicable to this document.

Implementations MUST ensure that malformed TLVs and sub-TLVs defined in this document are detected and do not provide a vulnerability for attackers to crash the OSPF router or routing process. Reception of malformed TLVs or sub-TLVs SHOULD be counted and/or logged for further analysis. Logging of malformed TLVs and sub-TLVs SHOULD be rate-limited to prevent a Denial-of-Service (DoS) attack (distributed or otherwise) from overloading the OSPF control plane.

The included security information MUST NOT be considered by the receiver if the originator did not protect the element carrying it with a mechanism that guarantees its integrity and protects it from replay attack by adequate means such as strong fingerprinting including a nonce such as provided by [RFC7474] or [RFC5304] although the last one does not provide adequate protection against replay attacks.

Advertisement of an incorrect security information may have negative consequences if e.g. actions like node sequestration are performed based on this information.

The presence of this information may also inform an attacker about vulnerable points in the network unless confidentiality along all flooding paths is provided.

10. Acknowledgements

11. References

11.1. Informative References

Venter, H.S., "A taxonomy for information security technologies", Computer & Security 22, , <>.

11.2. Normative References

Britto, W., Hegde, S., Kaneriya, P., Shetty, R., Bonica, R., and P. Psenak, "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks", Work in Progress, Internet-Draft, draft-ietf-lsr-ip-flexalgo-17, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, , <>.
Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, , <>.
Hartman, S. and D. Zhang, "Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6863, DOI 10.17487/RFC6863, , <>.
Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, , <>.
Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, , <>.
Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, , <>.
Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, , <>.
Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, , <>.
Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, , <>.

Authors' Addresses

Tony Przygienda (editor)
1137 Innovation Way
Sunnyvale, CA
United States of America
Acee Lindem
LabN Networks, L.L.C.
301 Midenhall Way
Cary, NC
United States of America
Vinayaka Guntanakkala
Juniper Networks