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

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 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).

Glossary The following terms are used in this document.

OSPF:: Open Shortest Path First
IS-IS:: Intermediate System to Intermediate System
LSA:: Link State Advertisement
RI:: Router Information
NSI:: Node Security Information
LSI:: Link Security Information
sec-characteristic:: 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.
sec-property:: 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:: 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).
null:: 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.
null-vector:: 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:: |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.

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: 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: 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.

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.

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.

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.

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:

sec-property-type:: Value that identifies the specific property, e.g., ospf sha-2. Contrary to expectations, this is not used except for informational purposes.
sec-property-strength:: this defines the first part of the comparison relation. sec-property with higher strength is considered "stronger" than sec-property with lower strength.
sec-property-attribute:: 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.
sec-property-flags:: 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.

Encodings

Node Security Information Advertisement for OSPF The Node Security Information TLV within the body of the OSPF RI Opaque LSA 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.

Node Security Information TLV for OSPF where:

Type:: 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 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 and has a type of ?. The type indicates the according security characteristic, i.e., confidentiality, integrity, availability.
Length:: variable; same as defined in Section ?.
Value:: Vector of ordered sec-property elements.

Format of the vector:

Flags:: 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.
Sec-Type:: 8 bit field that defines the sec-property-type which is not compared and only carried for information purposes.
Sec-Strength:: 8 bit field that defines the sec-property-strength which is compared with higher value indicating a stronger, i.e., "more secure" property.
Sec-Attribute:: 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.

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

Node Security Information Sub-TLV where:

Type:: TBD
Length:: variable; same as defined in Section ?.
Value:: equivalent to OSPF with reduced field lenghts.

Link Security Information Advertisement for OSPF The Link Security Information sub-TLV is defined to carry the security state of the interface associated with the link and has the same format as Node Security Information TLV with type reserved as TDB while the security types are reserved from its own registry. If this sub-TLV is advertised multiple times for the same link in different OSPF Extended Link Opaque LSAs / E-Router-LSAs originated by the same OSPF router, the sub-TLV in the OSPFv2 Extended Link Opaque LSA with the smallest Opaque ID or in the OSPFv3 E-Router-LSA with the smallest Link State ID MUST be used by receiving OSPF routers. This situation SHOULD be logged as an error. This sub-TLV is optional and indicates implicit null vector if not present. The scope of the advertisement is specific to the deployment.

Link Security Information Advertisement for IS-IS 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.

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.

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.

Applications One possible, obvious application is to include nodes that meet security criteria in Flex Algorithm or IP Flex Algorithm or use the information as a type of single or multi-dimensional metric.

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

Security Considerations Security concerns for OSPF are addressed in , , and . Further security analysis for the OSPF protocol is done in . Security considerations as specified by , , and 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 or 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.

Acknowledgements