INTERNET-DRAFT W A Simpson
DayDreamer
Intended status: Experimental 18 May 2011
Generation of Unique IS-IS System Identifiers
draft-simpson-isis-ppp-unique-01
Abstract
The IS-IS routing protocol (Intermediate System to Intermediate
System, ISO 10589) requires unique System Identifiers at the link
layer. A common practice has been to use an existing IEEE 802 MAC
link-layer interface identifier. When no unique MAC is available,
this document specifies automatic generation of identifiers. It is
fully interoperable with systems that do not support this extension.
Additionally, the extension automatically resolves conflicts between
System Identifiers.
Copyright Notice
Copyright (c) 2011 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
(http://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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
This document may not be modified, and derivative works of it may not
be created, except to format it for publication as an RFC or to
translate it into languages other than English.
Simpson expires November 18, 2011 [Page i]
DRAFT ISIS Unique 18 May 2011
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 http://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."
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Terminology . . . . . . . . . . . . . . . . . . . 1
2. Random Generation . . . . . . . . . . . . . . . . . . . 1
2.1 PPP Links . . . . . . . . . . . . . . . . . . . . 2
3. Resolving Conflicts . . . . . . . . . . . . . . . . . . 3
ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . 3
IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . 4
OPERATIONAL CONSIDERATIONS . . . . . . . . . . . . . . . . . . 4
SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 4
NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . . 5
INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 5
CONTACTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Simpson expires November 18, 2011 [Page ii]
DRAFT ISIS Unique 18 May 2011
1. Introduction
The System Identifier is 6 octets for OSI end systems, and 7 octets
for IS-IS routers or pseudonodes. This identifier is not required to
be the Destination or Source of any packet. (See [ISO10589],
[RFC1195], and [RFC5342] for further details.)
Typically, IS-IS implementations base the identifier on an existing
Media Access Control (MAC) link-layer interface identifier. The
48-bit MAC is usually composed of a 24-bit Organizationally Unique
Identifier (OUI) followed by a 24-bit Network Interface Controller
(NIC) specific number.
Other systems have a configured identifier that is independent of the
interfaces.
1.1. Terminology
The key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED",
"REQUIRED", "SHOULD", and "SHOULD NOT" in this document are to be
interpreted as described in [RFC2119].
2. Random Generation
Some systems have only point-to-point or other links without any
conveniently available MAC, and do not have a configured identifier.
This status might change dynamically, as hot swap interfaces are
added or removed.
In this case, a 48-bit System Identifier MUST be randomly generated.
(See [RFC4086] for requirements.)
To mitigate against potential assignment conflicts, this System
Identifier (considered as a pseudo-MAC) MUST have both the "locally-
assigned" and "broadcast/multicast" (group) bits set; that is, the
least significant two bits of the most significant octet are equal to
0x3.
The probability of conflict is reduced to a birthday attack of the
order N/2**23; where N is the number of systems in the same IS-IS
area. [Schneier] This is considerably less likely than a duplicate
MAC (see below).
Simpson expires November 18, 2011 [Page 1]
DRAFT ISIS Unique 18 May 2011
2.1. PPP Links
PPP [RFC1661] links (such as [RFC1377]) already specify negotiation
of a randomly generated unique 32-bit Magic Number "to detect looped-
back links and other Data Link Layer anomalies." Although only a
single interface negotiation is described in the main document, it
has long been understood [RFC1220] [Simpson1992] [Baker1992] that the
term "unique" applies across all local system interfaces. This
protects against patch-panel errors in addition to looped-back
modems, to detect unexpected loopbacks of a link from an endpoint to
itself. [Simpson1993] [RFC1663] [RFC1717]
An implementation conforming with this specification MUST have
different Magic Numbers for every link in a single system, and each
end of every link between two peers MUST have Magic Numbers which are
unique to those peers. That is, the Magic Number MUST be unique for
all visible interfaces.
Whenever such a Magic Number has been successfully negotiated, only
the most significant 2 octets of a pseudo-OUI are randomly generated,
followed by (concatenated to) the selected Magic Number.
To mitigate against potential assignment conflicts, this System
Identifier (considered as a pseudo-OUI) MUST have both the "locally-
assigned" and "broadcast/multicast" (group) bits set; that is, the
least significant two bits of the most significant octet are equal to
0x3.
The probability of conflict is considerably less than the wholly
generated pseudo-MAC (above), as the Magic Number has already been
determined to be locally unique. The pseudo-OUI differentiates among
PPP systems in the same IS-IS area.
Simpson expires November 18, 2011 [Page 2]
DRAFT ISIS Unique 18 May 2011
3. Resolving Conflicts
Field experience has shown that IEEE 802 MAC identifiers are
frequently not unique. Companies that manufacture more than 2**24
(16,777,214) devices will often reuse the same MAC. The probability
of conflict is defined by a birthday attack of the order N/2**16;
where N is the number of systems in the same IS-IS area.
Also, many companies reuse the same MAC for different product lines,
or different speeds or types of media. Some implementations failed
to correctly convert the MAC to canonical form [RFC2469], causing
unintentional conflicts through multi-media bridges.
If a duplicated MAC is used as a System Identifier within an IS-IS
area, this leads to the condition colloquially called "LSR War".
Currently, IS-IS has no method to detect or resolve such conflicts.
After detecting a conflicting System Identifier in a neighbor, or
receiving 3 or more IS-IS Hellos and failing to resolve participation
in an area within 10 seconds, an implementation conforming with this
specification MUST generate a replacement System Identifier using one
of the techniques specified above.
The system SHOULD delay generation and transmission of this
replacement System Identifier for a random amount of time between 0
and MAX_GENERATION_DELAY. Although the randomization range is
specified in units of seconds, the actual randomly-chosen value
SHOULD NOT be in units of whole seconds, but rather in units of the
highest available timer resolution.
This reduces the probability of synchronization with advertisements
from other systems in the same IS-IS area. If a message is received
during the delay indicating the conflict was resolved by another
system, the existing local System Identifier remains unchanged.
Acknowledgments
This document parallels text originally in [RFC2153] and various
other drafts.
James Carlson, Donald Eastlake, Dave Katz, and Radia Perlman provided
background information and helpful comments.
Simpson expires November 18, 2011 [Page 3]
DRAFT ISIS Unique 18 May 2011
IANA Considerations
This document has no IANA actions.
[RFC Editor: please remove this section prior to publication.]
Operational Considerations
MAX_GENERATION_DELAY
Default: 1 second. This is based on an anticipated IS-IS Hello
interval of no more than 4 seconds.
When Hellos are sent at a greater time interval, this MUST NOT be
greater than interval/2, and SHOULD NOT be greater than
interval/4.
Configurable System Identifier
Default 0 (off). Although the probability of conflict with
another System Identifier is minuscule, some implementations might
not have a sufficient source of randomness, and could repeatedly
select conflicting values. An implementation conforming with this
specification SHOULD have the capability to manually re-configure
the System Identifier, preventing random generation of a
replacement System Identifier.
To mitigate against potential assignment conflicts, this System
Identifier (considered as a pseudo-MAC) MUST have the "locally-
assigned" bit set and "broadcast/multicast" (group) bit clear;
that is, the least significant two bits of the most significant
octet are equal to 0x2.
Security Considerations
These mechanisms provide protection against compromised,
malfunctioning, or misconfigured systems [RFC4593]; spoofing attacks
are thwarted by quickly renegotiating a replacement System
Identifier.
Never-the-less, [RFC5304] increases protection against maliciously
configured conflicting System Identifiers.
Simpson expires November 18, 2011 [Page 4]
DRAFT ISIS Unique 18 May 2011
Normative References
[ISO10589] ISO/IEC 10589:2002, "Intermediate system to Intermediate
system routeing information exchange protocol for use in
conjunction with the Protocol for providing the
Connectionless-mode Network Service (ISO 8473)"
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", December 1990.
[RFC1377] Katz, D., "The PPP OSI Network Layer Control Protocol
(OSINLCP)", November 1992.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997.
[RFC4086] Eastlake, D. (3rd), Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, June
2005.
Informative References
[Baker1992] Baker, F., "PPP Reliable and Multi-Link Transmission",
Message to PPP Compression List, June 29, 1992. Message-
Id: <9206292135.AA00620@saffron.acc.com>
[RFC1220] Baker, F., "Point-to-Point Protocol extensions for
bridging", April 1991.
[RFC1663] Rand, D., "PPP Reliable Transmission", July 1994.
[RFC1717] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The
PPP Multilink Protocol (MP)", November 1994.
[RFC2153] Simpson, W., "PPP Vendor Extensions", May 1997.
[RFC2469] Narten, T., and C. Burton, "A Caution On The Canonical
Ordering Of Link-Layer Addresses", December 1998.
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", October 2006.
Simpson expires November 18, 2011 [Page 5]
DRAFT ISIS Unique 18 May 2011
[RFC5304] Li, T., and R. Atkinson, "IS-IS Cryptographic
Authentication", October 2008.
[RFC5342] Eastlake 3rd, D., "IANA Considerations and IETF Protocol
Usage for IEEE 802 Parameters", BCP 141, September 2008.
[Schneier] Schneier, B., "Applied Cryptography", John Wiley & Sons,
1996. ISBN 0-471-11709-9.
[Simpson1992]
Simpson, W., "where are we?", Message to IESG and others,
April 17, 1992. Message-Id:
<269.bsimpson@vela.acs.oakland.edu>
[Simpson1993]
Simpson, W., "Re: Simple Multilink Proceedure for PPP -
the document", Message to ietf-ppp and iplpdn mailing
lists, February 21, 1993. Message-Id:
<988.bill.simpson@um.cc.umich.edu>
Author's Address
Questions about this document can be directed to:
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
William.Allen.Simpson@Gmail.com
Simpson expires November 18, 2011 [Page 6]