Re: draft-simpson-isis-ppp-unique-00b
Donald Eastlake <[email protected]> Tue, 29 Mar 2011 14:31:11 +0200
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
Hi, Just a couple little quick comments from my point of view. I mentioned yesterday at the ISIS Working Group meeting that this draft was coming. Thanks, Donald On Thu, Mar 17, 2011 at 8:24 PM, William Allen Simpson <[email protected]> wrote: >... > > INTERNET-DRAFT W A Simpson > DayDreamer > Intended status: Standards Track 17 March 2011 > > > Generation of Unique IS-IS System Identifiers > draft-simpson-isis-ppp-unique-00b > > > 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 address. When no unique MAC address 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 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. > > 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 > > > > Simpson expires August 17, 2011 [Page i] > DRAFT ISIS Unique 17 March 2011 > > > 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 . . . . . . . . . . . . . . . . . . 2 > ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . 3 > IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . 3 > OPERATIONAL CONSIDERATIONS . . . . . . . . . . . . . . . . . . 3 > SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 3 > NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . . 4 > INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 4 > CONTACTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > >... > > Simpson expires August 17, 2011 [Page ii] > DRAFT ISIS Unique 17 March 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 6 > octet Media Access Control (MAC) identifier defined for one of its > link-layer interfaces. The 48-bit MAC is composed of a 24-bit "... is *usually* composed ..." Also add a reference to [RFC3452]. These days you can get an 36 bit prefix, called an Individual Address Block, which is cheaper than a 24 bit OUI pre-fix. > 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 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. Suggest "only point-to-point links without any conveniently available MAC" -> "only point-to-point or other links that do not have an associated MAC address" There could be some exotic link that isn't p2p but doesn't use MAC addresses. > 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. This is considerably less likely than a duplicate MAC (see > below), or operating facility destruction by meteor, or an operator's > death by lightning strike. [Schneier] > > > > > > Simpson expires August 17, 2011 [Page 1] > DRAFT ISIS Unique 17 March 2011 > > > 2.1. PPP Links > > PPP [RFC1661] links (such as [RFC1377]) already specify negotiation > of a 32-bit Magic Number. As currently used in [RFC1663] and > [RFC1990], every link in a single system MUST have different Magic > Numbers, and each end of every link between two peers SHOULD have > Magic Numbers which are unique to those peers. This protects against > patch-panel errors in addition to looped-back links. > > An implementation conforming with this specification MUST ensure this > Magic Number is unique for all local interfaces, and also MUST be > unique for all negotiated peer interfaces. Whenever a Magic Number > has been successfully negotiated, only the most significant 2 octets > of a pseudo-OUI are randomly generated. The selected Magic Number is > appended after the pseudo-OUI. > > 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 > such PPP-only systems. > > > 3. Resolving Conflicts > > Field experience has shown that IEEE 802 MAC addresses are frequently > not unique. Companies that manufacture more than 16,777,214 devices > will often reuse the same MAC. > > 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], resulting > 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 30 seconds, an implementation conforming with this > specification MUST generate a replacement System Identifier using one > of the techniques specified above. > > > > Simpson expires August 17, 2011 [Page 2] > DRAFT ISIS Unique 17 March 2011 > > > Acknowledgments > > This document parallels text originally in [RFC2153]. > > James Carlson, Donald Eastlake, and Dave Katz provided background > information and helpful comments. > > > IANA Considerations > > This document has no IANA actions. > > [RFC Editor: please remove this section prior to publication.] > > > Operational Considerations > > 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 MUST have an option > to statically configure the System Identifier. Default 0 (off). > > 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 August 17, 2011 [Page 3] > DRAFT ISIS Unique 17 March 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] > > [RFC1377] > > [RFC1661] > > [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 > > [RFC1663] > > [RFC1990] > > [RFC2153] > > [RFC2469] > > [RFC4593] > > [RFC5304] > > [RFC5342] > > [Schneier] > >... > > Simpson expires August 17, 2011 [Page 4] > DRAFT ISIS Unique 17 March 2011 > > > 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 > > [email protected] > >... > > > Simpson expires August 17, 2011 [Page 5] _______________________________________________ Pppext mailing list [email protected] https://www.ietf.org/mailman/listinfo/pppext