Network Working Group A. Przygienda, Ed. Internet-Draft Juniper Intended status: Experimental A. Lindem Expires: 24 April 2024 LabN Networks, L.L.C. G. Guntanakkala Juniper Networks 22 October 2023 Advertising Link and Node Security Properties in OSPF/IS-IS draft-przygienda-lsr-ospf-security-states-00 Abstract 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 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. Przygienda, et al. Expires 24 April 2024 [Page 1] Internet-Draft IGP Link/Node Security Advertisement October 2023 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. First Example . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 5 3.2. Availability . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Extensible Ordering Relation . . . . . . . . . . . . . . . . 6 5. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Node Security Information Advertisement for OSPF . . . . 7 5.2. Node Security Information for IS-IS . . . . . . . . . . . 8 5.3. Link Security Information Advertisement for OSPF . . . . 9 5.4. Link Security Information Advertisement for IS-IS . . . . 10 5.4.1. Procedures for Defining and Using Node and Link Security Information Advertisements . . . . . . . . . 10 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Normative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 Przygienda, et al. Expires 24 April 2024 [Page 2] Internet-Draft IGP Link/Node Security Advertisement October 2023 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. 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. Przygienda, et al. Expires 24 April 2024 [Page 3] Internet-Draft IGP Link/Node Security Advertisement October 2023 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. 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: +=================+==========================================+ | 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 ] | +-----------------+------------------------------------------+ Table 1: Example Vector for A and in similar fashion for node B: Przygienda, et al. Expires 24 April 2024 [Page 4] Internet-Draft IGP Link/Node Security Advertisement October 2023 +=================+================================+ | C | v_C | +=================+================================+ | Confidentiality | [ mac-sec, ospf-sha-3 ] | +-----------------+--------------------------------+ | Integrity | [ 5% corruption data traffic ] | +-----------------+--------------------------------+ Table 2: Example Vector for B 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. Przygienda, et al. Expires 24 April 2024 [Page 5] Internet-Draft IGP Link/Node Security Advertisement October 2023 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: 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. Przygienda, et al. Expires 24 April 2024 [Page 6] Internet-Draft IGP Link/Node Security Advertisement October 2023 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 Przygienda, et al. Expires 24 April 2024 [Page 7] Internet-Draft IGP Link/Node Security Advertisement October 2023 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 [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. 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. 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. Przygienda, et al. Expires 24 April 2024 [Page 8] Internet-Draft IGP Link/Node Security Advertisement October 2023 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 where: Type: TBD Length: variable; same as defined in Section ?. Value: equivalent to OSPF with reduced field lenghts. 5.3. 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. Przygienda, et al. Expires 24 April 2024 [Page 9] Internet-Draft IGP Link/Node Security Advertisement October 2023 5.4. 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. 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. Przygienda, et al. Expires 24 April 2024 [Page 10] Internet-Draft IGP Link/Node Security Advertisement October 2023 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 Przygienda, et al. Expires 24 April 2024 [Page 11] Internet-Draft IGP Link/Node Security Advertisement October 2023 11. References 11.1. Informative References [CIA] Venter, H.S., "A taxonomy for information security technologies", Computer & Security 22, 2003, . 11.2. Normative References [I-D.ietf-lsr-ip-flexalgo] 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, 24 July 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC6863] 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, March 2013, . [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, . [RFC7474] 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, April 2015, . Przygienda, et al. Expires 24 April 2024 [Page 12] Internet-Draft IGP Link/Node Security Advertisement October 2023 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7770] 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, February 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, . Authors' Addresses Tony Przygienda (editor) Juniper 1137 Innovation Way Sunnyvale, CA United States of America Email: prz@juniper.net Acee Lindem LabN Networks, L.L.C. 301 Midenhall Way Cary, NC United States of America Email: acee.ietf@gmail.com Przygienda, et al. Expires 24 April 2024 [Page 13] Internet-Draft IGP Link/Node Security Advertisement October 2023 Vinayaka Guntanakkala Juniper Networks India Email: vinayakag@juniper.net Przygienda, et al. Expires 24 April 2024 [Page 14]