Internet DRAFT - draft-przygienda-lsr-ospf-security-states
draft-przygienda-lsr-ospf-security-states
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,
<https://doi.org/10.1016/S0167-4048(03)00406-1.>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-
flexalgo-17>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[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,
<https://www.rfc-editor.org/info/rfc6863>.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166,
DOI 10.17487/RFC7166, March 2014,
<https://www.rfc-editor.org/info/rfc7166>.
[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,
<https://www.rfc-editor.org/info/rfc7474>.
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, <https://www.rfc-editor.org/info/rfc7684>.
[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, <https://www.rfc-editor.org/info/rfc7770>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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, <https://www.rfc-editor.org/info/rfc8362>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
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]
