idnits 2.17.1 draft-simpson-isis-ppp-unique-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (8 August 2011) is 4643 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1220 (Obsoleted by RFC 1638) -- Obsolete informational reference (is this intentional?): RFC 1717 (Obsoleted by RFC 1990) -- Obsolete informational reference (is this intentional?): RFC 5342 (Obsoleted by RFC 7042) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT W A Simpson 3 DayDreamer 4 Intended status: Experimental 8 August 2011 6 Generation of Unique IS-IS System Identifiers 7 draft-simpson-isis-ppp-unique-02 9 Abstract 11 The IS-IS routing protocol (Intermediate System to Intermediate 12 System, ISO 10589) requires unique System Identifiers at the link 13 layer. A common practice has been to use an existing IEEE 802 MAC 14 link-layer interface identifier. When no unique MAC is available, 15 this document specifies automatic generation of identifiers. It is 16 fully interoperable with systems that do not support this extension. 18 Additionally, the extension automatically resolves conflicts between 19 System Identifiers. 21 Copyright Notice 23 Copyright (c) 2011 IETF Trust and the persons identified as the 24 document authors. All rights reserved. 26 This document is subject to BCP 78 and the IETF Trust's Legal 27 Provisions Relating to IETF Documents 28 (http://trustee.ietf.org/license-info) in effect on the date of 29 publication of this document. Please review these documents 30 carefully, as they describe your rights and restrictions with respect 31 to this document. 33 This document may contain material from IETF Documents or IETF 34 Contributions published or made publicly available before November 35 10, 2008. The person(s) controlling the copyright in some of this 36 material may not have granted the IETF Trust the right to allow 37 modifications of such material outside the IETF Standards Process. 39 This document may not be modified, and derivative works of it may not 40 be created, except to format it for publication as an RFC or to 41 translate it into languages other than English. 43 Status of this Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute working 50 documents as Internet-Drafts. The list of current Internet-Drafts is 51 at http://datatracker.ietf.org/drafts/current. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 1 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . 1 62 2. Random Generation . . . . . . . . . . . . . . . . . . . 2 63 2.1 PPP Links . . . . . . . . . . . . . . . . . . . . 2 64 3. Resolving Conflicts . . . . . . . . . . . . . . . . . . 3 65 ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . 4 66 IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . 4 67 OPERATIONAL CONSIDERATIONS . . . . . . . . . . . . . . . . . . 5 68 SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 5 69 NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . . 6 70 INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 6 71 CONTACTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The System Identifier is 6 octets for OSI end systems, and 7 octets 76 for IS-IS routers or pseudonodes. This identifier is not required to 77 be the Destination or Source of any packet. (See [ISO10589], 78 [RFC1195], and [RFC5342] for further details.) 80 Typically, IS-IS implementations base the identifier on an existing 81 Media Access Control (MAC) link-layer interface identifier. The 82 48-bit MAC is usually composed of a 24-bit Organizationally Unique 83 Identifier (OUI) followed by a 24-bit Network Interface Controller 84 (NIC) specific number. 86 Other systems have a configured identifier that is independent of the 87 interfaces. 89 When no unique MAC is available, this document specifies automatic 90 generation of identifiers. In the presence of PPP [RFC1661] links, 91 the PPP Magic Number is unique with respect to its neighbors and 92 further reduces the potential for conflict. 94 This mechanism is also necessary to resolve conflicts between 95 multiple systems with the same System Identifier due to manufacturing 96 or misconfiguration. 98 1.1. Terminology 100 The key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", 101 "REQUIRED", "SHOULD", and "SHOULD NOT" in this document are to be 102 interpreted as described in [RFC2119]. 104 2. Random Generation 106 Some systems have only point-to-point or other links without any 107 conveniently available MAC, and do not have a configured identifier. 108 This status might change dynamically, as hot swap interfaces are 109 added or removed. 111 In this case, a 48-bit System Identifier MUST be randomly generated. 112 (See [RFC4086] for requirements.) 114 To mitigate against potential assignment conflicts, this System 115 Identifier (considered as a pseudo-MAC) MUST have both the "locally- 116 assigned" and "broadcast/multicast" (group) bits set; that is, the 117 least significant two bits of the most significant octet are equal to 118 0x3. 120 The probability of conflict between these identifiers is of the order 121 (N**2)/(2**47); where N is the number of systems in the same IS-IS 122 area. This is considerably less likely than a duplicate MAC (see 123 below). 125 2.1. PPP Links 127 PPP [RFC1661] links (such as [RFC1377]) already specify negotiation 128 of a randomly generated unique 32-bit Magic Number "to detect looped- 129 back links and other Data Link Layer anomalies." Although only a 130 single interface negotiation is described in the main document, it 131 has long been understood [RFC1220] [Simpson1992] [Baker1992] that the 132 term "unique" applies across all local system interfaces. This 133 protects against patch-panel errors in addition to looped-back 134 modems, to detect unexpected loopbacks of a link from an endpoint to 135 itself. [Simpson1993] [RFC1663] [RFC1717] 137 An implementation conforming with this specification MUST have 138 different Magic Numbers for every link in a single system, and each 139 end of every link between two peers MUST have Magic Numbers which are 140 unique to those peers. That is, the Magic Number MUST be unique for 141 all visible interfaces. 143 Whenever such a Magic Number has been successfully negotiated, only 144 the most significant 2 octets of a pseudo-OUI are randomly generated, 145 followed by (concatenated to) the selected Magic Number. 147 To mitigate against potential assignment conflicts, this System 148 Identifier (considered as a pseudo-OUI) MUST have both the "locally- 149 assigned" and "broadcast/multicast" (group) bits set; that is, the 150 least significant two bits of the most significant octet are equal to 151 0x3. 153 The probability of conflict is considerably less than the wholly 154 generated pseudo-MAC (above), as the Magic Number has already been 155 determined to be locally unique. The pseudo-OUI differentiates among 156 PPP systems in the same IS-IS area. 158 3. Resolving Conflicts 160 As multiple systems generate System Identifiers, they might not have 161 sufficiently divergent random bits available (especially on startup). 162 Resolving conflicts is REQUIRED. 164 Field experience has shown that IEEE 802 MAC identifiers are 165 frequently not unique. Reuse is more likely to recycle a block 166 varying only the least significant bits, increasing the probability 167 considerably over a normal distribution. 169 A MAC is most often reused by companies that have defective 170 manufacturing processes, or manufacture more than 2**24 (16,777,214) 171 devices. Many companies reuse the same MAC for different product 172 lines, or different speeds or types of media. Some implementations 173 failed to correctly convert the MAC to canonical form [RFC2469], 174 causing unintentional conflicts through multi-media bridges. 176 If a duplicated MAC is used as a System Identifier within an IS-IS 177 area, this leads to the condition colloquially called "LSP War" or 178 "LSR War". The Update Process will increment its LSP sequence number 179 repeatedly. Currently, IS-IS has no method to autonomously resolve 180 conflicts. 182 An implementation conforming with this specification MUST generate a 183 replacement System Identifier using one of the techniques specified 184 above, upon: 186 (a) detecting a conflicting System Identifier in 188 (a)(1) 1 IS-IS Hello from any neighbor, or 190 (a)(2) 2 consecutive LSPs and/or SNPs from the same source; 192 (b) failing to resolve participation in an area after 194 (b)(1) incrementing its Sequence Number 3 or more times, and 196 (b)(2) 10 seconds. 198 This will not usually detect conflicts between different areas that 199 do not affect routing within those areas. Each system participating 200 in two or more areas MUST maintain a distinction between System 201 Identifiers found in each area. Never-the-less, any replacement 202 System Identifier SHOULD propagate in every such area. 204 The system SHOULD delay generation and transmission of this 205 replacement System Identifier for a random amount of time between 0 206 and MAX_GENERATION_DELAY. Although the randomization range is 207 specified in units of seconds, the actual randomly-chosen value 208 SHOULD NOT be in units of whole seconds, but rather in units of the 209 highest available timer resolution. 211 This reduces the probability of synchronization with advertisements 212 from other systems in the same IS-IS area. If a message is received 213 during the delay indicating the conflict was resolved by another 214 system, the existing local System Identifier remains unchanged. 216 Acknowledgments 218 This document parallels text originally in [RFC2153] and various 219 other drafts. 221 James Carlson, Donald Eastlake, Dave Katz, and Radia Perlman provided 222 background information and helpful comments. 224 Members of the IESG, ISIS WG, PPPext WG, and TRILL WG contributed 225 additional comments. 227 IANA Considerations 229 This document has no IANA actions. 231 [RFC Editor: please remove this section prior to publication.] 233 Operational Considerations 235 MAX_GENERATION_DELAY 236 Default: 1 second. This is based on an anticipated IS-IS Hello 237 interval of no more than 4 seconds. 239 When Hellos are sent at a greater time interval, this MUST NOT be 240 greater than interval/2, and SHOULD NOT be greater than 241 interval/4. 243 Configurable System Identifier 244 Default 0 (off). Although the probability of conflict with 245 another System Identifier is minuscule, some implementations might 246 not have a sufficient source of randomness, and could repeatedly 247 select conflicting values. An implementation conforming with this 248 specification SHOULD have the capability of manually configuring 249 the System Identifier, preventing random generation of a 250 replacement System Identifier. 252 To mitigate against potential assignment conflicts, this System 253 Identifier (considered as a pseudo-MAC) MUST have the "locally- 254 assigned" bit set and "broadcast/multicast" (group) bit clear; 255 that is, the least significant two bits of the most significant 256 octet are equal to 0x2. 258 Remote Management 259 Additional options have been suggested to configure other actions 260 taken upon detecting a conflicting System Identifier. For 261 example, the system might send an alert to a remote management 262 facility and disable IS-IS until remote management updates the 263 configuration. Such remote management configuration options are 264 beyond the scope of this specification. 266 Security Considerations 268 These mechanisms provide protection against compromised, 269 malfunctioning, or misconfigured systems [RFC4593]; spoofing attacks 270 are thwarted by quickly renegotiating a replacement System 271 Identifier. 273 Never-the-less, [RFC5304] increases protection against maliciously 274 configured conflicting System Identifiers. 276 Normative References 278 [ISO10589] ISO/IEC 10589:2002, "Intermediate system to Intermediate 279 system routeing information exchange protocol for use in 280 conjunction with the Protocol for providing the 281 Connectionless-mode Network Service (ISO 8473)" 283 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 284 dual environments", December 1990. 286 [RFC1377] Katz, D., "The PPP OSI Network Layer Control Protocol 287 (OSINLCP)", November 1992. 289 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 290 STD 51, July 1994. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, March 1997. 295 [RFC4086] Eastlake, D. (3rd), Schiller, J., and S. Crocker, 296 "Randomness Requirements for Security", BCP 106, June 297 2005. 299 Informative References 301 [Baker1992] Baker, F., "PPP Reliable and Multi-Link Transmission", 302 Message to PPP Compression List, June 29, 1992. Message- 303 Id: <9206292135.AA00620@saffron.acc.com> 305 [RFC1220] Baker, F., "Point-to-Point Protocol extensions for 306 bridging", April 1991. 308 [RFC1663] Rand, D., "PPP Reliable Transmission", July 1994. 310 [RFC1717] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The 311 PPP Multilink Protocol (MP)", November 1994. 313 [RFC2153] Simpson, W., "PPP Vendor Extensions", May 1997. 315 [RFC2469] Narten, T., and C. Burton, "A Caution On The Canonical 316 Ordering Of Link-Layer Addresses", December 1998. 318 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 319 Routing Protocols", October 2006. 321 [RFC5304] Li, T., and R. Atkinson, "IS-IS Cryptographic 322 Authentication", October 2008. 324 [RFC5342] Eastlake 3rd, D., "IANA Considerations and IETF Protocol 325 Usage for IEEE 802 Parameters", BCP 141, September 2008. 327 [Simpson1992] 328 Simpson, W., "where are we?", Message to IESG and others, 329 April 17, 1992. Message-Id: 330 <269.bsimpson@vela.acs.oakland.edu> 332 [Simpson1993] 333 Simpson, W., "Re: Simple Multilink Proceedure for PPP - 334 the document", Message to ietf-ppp and iplpdn mailing 335 lists, February 21, 1993. Message-Id: 336 <988.bill.simpson@um.cc.umich.edu> 338 Author's Address 340 Questions about this document can be directed to: 342 William Allen Simpson 343 DayDreamer 344 Computer Systems Consulting Services 345 1384 Fontaine 346 Madison Heights, Michigan 48071 348 William.Allen.Simpson@Gmail.com