[Pppext] draft-simpson-isis-ppp-unique-00c
William Allen Simpson <william.allen.simpson@gmail.com> Wed, 30 March 2011 02:47 UTC
Return-Path: <william.allen.simpson@gmail.com>
X-Original-To: pppext@core3.amsl.com
Delivered-To: pppext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11233A6840 for <pppext@core3.amsl.com>; Tue, 29 Mar 2011 19:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.477
X-Spam-Level:
X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmAAEpiYza04 for <pppext@core3.amsl.com>; Tue, 29 Mar 2011 19:47:39 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 952053A6834 for <pppext@ietf.org>; Tue, 29 Mar 2011 19:47:39 -0700 (PDT)
Received: by iwn39 with SMTP id 39so882297iwn.31 for <pppext@ietf.org>; Tue, 29 Mar 2011 19:49:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=495qL7jgUGks2tPVm11PtWzPnP9PNF85YdrutRmeFGQ=; b=oHo6OTsIp+JNvWbJo1U4xlCe3rKmKbh2NcozgwgCa+meRu66y9fconZAMP/g5iWppV zOSjuX7OtwDlk61Hvab/qyQga2NbUKjljfIW8WuNcY2yiEhtbP74ZjBUxkqL4Cp2LvGP Yanrje4NVuuMz3BpshGkoWJVOwf2nJW14t2jQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=dIBWj9ggyLhIEm8dDGCixDcY4rPgxEJQfqzqtsRfJfbGJqpZtz5Adc//VM+rvzZyP8 FbvH8yi0QUd89563Lr+NWHvQJ8V/dovm4cuanis/7HuOSSZLZhRngliPoZLsHlCj8uE0 wFneRlBckr3foM57Ij+AQ9WmtP2SHWXaTBNbA=
Received: by 10.42.131.72 with SMTP id y8mr403606ics.283.1301453356466; Tue, 29 Mar 2011 19:49:16 -0700 (PDT)
Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id uk4sm3727826icb.9.2011.03.29.19.49.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 19:49:15 -0700 (PDT)
Message-ID: <4D929A29.5040903@gmail.com>
Date: Tue, 29 Mar 2011 22:49:13 -0400
From: William Allen Simpson <william.allen.simpson@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: IETF PPP Extensions <pppext@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Pppext] draft-simpson-isis-ppp-unique-00c
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2011 02:47:41 -0000
Includes changes discussed, with changebars. The internet-draft (sans c) does not include the changebars. === INTERNET-DRAFT W A Simpson DayDreamer Intended status: Standards Track 29 March 2011 Generation of Unique IS-IS System Identifiers | draft-simpson-isis-ppp-unique-00c | 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 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 29, 2011 [Page i] DRAFT ISIS Unique 29 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 . . . . . . . . . . . . . . . . . . 4 SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 4 NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . . 5 INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 5 CONTACTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Simpson expires August 29, 2011 [Page ii] DRAFT ISIS Unique 29 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 | 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. 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 29, 2011 [Page 1] DRAFT ISIS Unique 29 March 2011 2.1. PPP Links PPP [RFC1661] links (such as [RFC1377]) already specify negotiation | of a unique 32-bit Magic Number. Although only a single interface | negotiation is described in the base 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. 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 identifiers 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. Simpson expires August 29, 2011 [Page 2] DRAFT ISIS Unique 29 March 2011 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, 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.] Simpson expires August 29, 2011 [Page 3] DRAFT ISIS Unique 29 March 2011 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 MUST have an option to statically configure the 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 August 29, 2011 [Page 4] DRAFT ISIS Unique 29 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] 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 August 29, 2011 [Page 5] DRAFT ISIS Unique 29 March 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 August 29, 2011 [Page 6]
- [Pppext] draft-simpson-isis-ppp-unique-00c William Allen Simpson
- Re: [Pppext] draft-simpson-isis-ppp-unique-00c William Allen Simpson