| Internet-Draft | IGP Link/Node Security Advertisement | October 2023 |
| Przygienda, et al. | Expires 24 April 2024 | [Page] |
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.¶
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.¶
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 https://datatracker.ietf.org/drafts/current/.¶
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.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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).¶
The following terms are used in this document.¶
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:¶
| 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:¶
| 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.¶
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.¶
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.¶
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.¶
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:¶
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.¶
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 .. |
where:¶
Format of the vector:¶
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.¶
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 ..
where:¶
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.¶
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.¶
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.¶
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.¶
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.¶
This document requests allocation for the following code points and registries.¶
...¶
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.¶