Re: [Pppext] draft-simpson-isis-ppp-unique-00b

[Donald Eastlake <[e-mail]>]

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
<[e-mail]> 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
>
>          [e-mail]
>
>...
>
>
> Simpson                  expires August 17, 2011                [Page 5]