idnits 2.17.1 draft-retana-lsr-ospf-monitor-node-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 780 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Link State Routing A. Retana 3 Internet-Draft L. Han 4 Intended status: Standards Track Futurewei Technologies, Inc. 5 Expires: 8 September 2022 7 March 2022 7 OSPF Monitor Node 8 draft-retana-lsr-ospf-monitor-node-00 10 Abstract 12 This document specifies mechanisms that allow a node to monitor an 13 OSPF network actively without influencing the topology or affecting 14 its stability. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 8 September 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 51 2. Router Interface Parameters . . . . . . . . . . . . . . . . . 3 52 3. Monitoring Interface . . . . . . . . . . . . . . . . . . . . 3 53 4. The Monitor Node Option . . . . . . . . . . . . . . . . . . . 4 54 5. Operational Considerations . . . . . . . . . . . . . . . . . 4 55 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 9.2. Informative References . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 Monitoring the control plane activity in a network is essential to 66 designing and maintaining a robust and stable network. Passive 67 (listen- only) devices deployed in broadcast or non-broadcast multi- 68 access (NBMA) networks have typically satisfied the need. However, 69 passive devices depend on more than two routers being present in the 70 network and are not visible to the network operator -- anyone can 71 listen. 73 An alternative implementation, primarily used in point-to-point 74 interfaces, or in cases where the listening device is the only other 75 node on the interface, is to participate fully in the protocol: 76 create a full adjacency with the closest router, participate in 77 designated router (DR) election, etc. The node is now visible in the 78 network, can advertise control plane information, and any changes in 79 its status are flooded throughout the network. Many link state 80 advertisements (LSA) or state changes can cause instability in the 81 network, and additional configuration is usually needed to avoid the 82 device becoming a transit node. 84 This document specifies mechanisms that allow a node to monitor OSPF 85 activity without influencing the topology or affecting its stability 86 while being fully adjacent and known to the network operator. These 87 nodes are referred to as a Monitor Node. Two such mechanisms are 88 introduced: 90 Section 3 describes a local implementation to be used in the case 91 where the Monitor Node is the only other router on an interface. 93 Section 4 specifies signaling in the Hello message for a node to 94 communicate its intention to become a Monitor Node. 96 The mechanisms presented apply to both OSPFv2 [RFC2328] and OSPFv3 97 [RFC5340]. The term OSPF is used to refer to both versions. 99 1.1. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 2. Router Interface Parameters 109 This document defines the following router interface configurable 110 parameters: 112 DoNotAdvertiseLink 113 Indicates whether or not the link is advertised on the local 114 router-LSA. If set to "enabled," the router MUST NOT include 115 a corresponding interface description in its router-LSA. The 116 router MUST NOT originate other LSAs related to the link or 117 its addresses. Enabling this interface parameter overrides 118 the setting of LinkLSASuppression [RFC5340]. 120 DoNotRequestAndIgnoreLSAs 121 Indicates whether or not the router should request and use 122 LSAs from other routers on this interface. If set to 123 "enabled," the router MUST consider its Link state request 124 list empty. Also, the router MUST consider the LS age of any 125 received LSA to be equal to MaxAge and process it according 126 to Section 13 of [RFC2328]. 128 3. Monitoring Interface 130 By using the interface parameters specified in Section 2, a router 131 can treat all neighbors on the interface as Monitor Nodes. To do so, 132 DoNotAdvertiseLink and DoNotRequestAndIgnoreLSAs SHOULD be configured 133 simultaneously. If either parameter is configured on a broadcast or 134 NBMA interface, the router MUST NOT participate in the Designated 135 Router (DR) selection process. 137 Enabling DoNotAdvertiseLink by itself results in any LSAs originated 138 by the Monitor Node not being resolved in the routing table. 140 If only DoNotRequestAndIgnoreLSAs is enabled, the router MUST treat 141 the link as a stub network. Note that the neighbor information 142 (corresponding to the Monitor Node) is not advertised. 144 4. The Monitor Node Option 146 This document defines a new Option in the Extended Options and Flags 147 (EOF) Link-Local Signaling (LLS) TLV [RFC5613]. The new option is 148 called Monitor (M-bit) and has a value of TBD. 150 When set, the M-bit indicates that the originating router is a 151 Monitor Node. Other routers on the same link MUST: 153 * Consider the Monitor Node ineligible for the DR selection process. 155 * Consider its Link state request list empty with respect to the 156 Monitor Node. 158 * Consider the LS age of any LSA received from the Monitor Node is 159 equal to MaxAge. 161 If the Monitor Node is one of only two routers on an interface, the 162 other router MUST NOT include a corresponding interface description 163 in its router-LSA. Furthermore, other LSAs related to the link or 164 its addresses MUST NOT be originated. This situation overrides the 165 setting of LinkLSASuppression. 167 5. Operational Considerations 169 The use of the monitoring interface (Section 3) applies to all other 170 routers on the same interface. While the Monitor Node option 171 (Section 4) applies to only the router signaling the M-bit. Network 172 administrators should use the Monitor Node option in transit 173 interfaces where one router is a Monitor Node. 175 If the Monitor Node is the only other router on an interface, the 176 link information can be advertised (as a stub link) if only 177 DoNotRequestAndIgnoreLSAs is enabled. 179 The deployment of the Monitoring Interface (Section 3) requires that 180 only the non-Monitor Node supports this specification. On the other 181 hand, the Monitor Node Option (Section 4) requires all nodes on the 182 interface to support the functionality. If support is not present in 183 all the routers on the link, the Monitor Node will be eligible to be 184 a DR, and its information may be flooded through the network. 186 6. Acknowledgements 188 TBD 190 7. IANA Considerations 192 IANA is requested to allocate a value (TBD) from the "LLS Type 1 193 Extended Options and Flags" registry for the M-bit (Section 4). 195 8. Security Considerations 197 The security considerations documented in [RFC2328], [RFC5340], and 198 [RFC5613] apply to this extension. 200 This document defines a new type of node, called a Monitor Node, 201 intended only to receive information from its neighbors and not send 202 any. If the LSAs from the Monitor Node are not ignored, they will be 203 flooded throughout the network. A rouge Monitor Node may advertise 204 LSAs with an Advertising Router field that doesn't correspond to its 205 router ID. This type of vulnerability is not new, but it is already 206 present in the base specification. 208 Even though it is expected that the local network operator deploys 209 any Monitor Node, authentication mechanisms such as those specified 210 in [RFC5709], [RFC7474], [RFC4552], or [RFC7166] SHOULD be used. 212 9. References 214 9.1. Normative References 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, 218 DOI 10.17487/RFC2119, March 1997, 219 . 221 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 222 DOI 10.17487/RFC2328, April 1998, 223 . 225 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 226 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 227 . 229 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 230 Yeung, "OSPF Link-Local Signaling", RFC 5613, 231 DOI 10.17487/RFC5613, August 2009, 232 . 234 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 235 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 236 May 2017, . 238 9.2. Informative References 240 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 241 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 242 . 244 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 245 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 246 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 247 2009, . 249 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 250 Authentication Trailer for OSPFv3", RFC 7166, 251 DOI 10.17487/RFC7166, March 2014, 252 . 254 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 255 "Security Extension for OSPFv2 When Using Manual Key 256 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 257 . 259 Authors' Addresses 261 Alvaro Retana 262 Futurewei Technologies, Inc. 263 2330 Central Expressway 264 Santa Clara, CA 95050 265 United States of America 266 Email: aretana@futurewei.com 268 Lin Han 269 Futurewei Technologies, Inc. 270 2330 Central Expressway 271 Santa Clara, CA 95050 272 United States of America 273 Email: lin.han@futurewei.com