http://blog.gmane.org/gmane.ietf.pppext hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.pppext/1224 <pre>Hi, Our AD is interested in a plan to upgrade appropriate PPP standards track RFCs to full Standard. A change in state can, under the right circumstances, be done without a new RFC. I think it would be appropriate, as I have suggested before, to review the PPP security RFCs with a view, in each case, to moving to Historic those which don't meet modern security standards or to obsolete them with a new version which does... The later would require a Charter change. To quote from the existing PPPEXT Charter: "The group may, however, advance existing specifications to the next level in the standards track, if a need for that comes up. Similarly, the group may classify existing specifications as Historic where this is appropriate." I'd be interested in any comments. If there is any desire for a brief meeting in Berlin to discuss this sort of thing, this would be a good time to request it. (I just noticed that the session request tool has an option to request a 1/2 hour meeting which I never noticed before. While WGs have had very short meetings, I can't recall one scheduled for less than 1 hour...) I suspect such a meeting at the next IETF Meeting in Berlin is not necessary... Thanks, Donald [PPPEXT Chair] ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3&lt; at &gt;gmail.com _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> Donald Eastlake 2013-05-12T10:01:00 http://comments.gmane.org/gmane.ietf.pppext/1223 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> johnsonhammond1< at >hushmail.com 2013-04-27T17:27:59 http://comments.gmane.org/gmane.ietf.pppext/1186 <pre>Hi, In case you were unaware, I am now the Chair of PPPEXT. Generally, there has been little activity in this WG for some years. Although I believe it serves a useful purpose in examining PPP proposals, possibly that purpose could be served by just continuing the mailing list. In any case, it seems likely that, if the situation continues unchanged, the WG will be dissolved sometime early next year. In the process of producing RFC 6361, it became very apparent that the PPP security RFCs, such as they are, meet few, if any, modern IETF security guidelines. I believe that there should be an update of PPP security or, if an effort to update them fails for some reason, then at least old / inadequate / unimplemented PPP security RFCs should be declared historic. My suggestion is that PPPEXT re-Charter to include a goal such as the above and I'm willing to try drafting a new Charter but welcome suggestions and comments on all this. One question is, should PPPEXT have a 1 hour meeting at the November IETF meeting? I think that would be the best way to come to consensus on this but obviously only if enough people would plan to actually attend. So, I'd be interested in who is would attend and any opinions for or against such a meeting. Thanks, Donald =============================  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)  155 Beaver Street, Milford, MA 01757 USA  d3e3e3&lt; at &gt;gmail.com _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> Donald Eastlake 2011-09-08T22:24:24 http://comments.gmane.org/gmane.ietf.pppext/1179 <pre>Preparing to watch some IETF meetings, I belatedly noticed this. Because it is now an independent submission, it wasn't sent to the pppext list. -------- Original Message -------- Subject: I-D Action: draft-ietf-pppext-trill-protocol-08.txt Date: Tue, 14 Jun 2011 15:07:01 -0700 From: internet-drafts&lt; at &gt;ietf.org Reply-To: internet-drafts&lt; at &gt;ietf.org To: i-d-announce&lt; at &gt;ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PPP TRILL Protocol Control Protocol Author(s) : James Carlson Donald Eastlake Filename : draft-ietf-pppext-trill-protocol-08.txt Pages : 11 Date : 2011-06-14 The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-08.txt _______________________________________________ I-D-Announce mailing list I-D-Announce&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> William Allen Simpson 2011-07-25T15:11:55 http://comments.gmane.org/gmane.ietf.pppext/1164 <pre>A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP TRILL Protocol Control Protocol Author(s) : James Carlson Filename : draft-ietf-pppext-trill-protocol-07.txt Pages : 7 Date : 2011-06-03 The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-07.txt _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> internet-drafts< at >ietf.org 2011-06-03T19:45:15 http://comments.gmane.org/gmane.ietf.pppext/1144 <pre>As part of IETF review, the Routing ADs are looking over draft-ietf-pppext-trill-protocol-06. Not too surprising to me -- given that I still think it's far out of scope -- the text concerning IS-IS System IDs is causing trouble in that review. See this thread: http://www.ietf.org/mail-archive/web/rtg-dir/current/threads.html#01533 I wish I could leave the worms safely in the can, but it's looking like that might not be one of the options. Instead of the reference to Bill Simpson's draft, Stewart Bryant suggested replacement text like this: ISO/IEC 10589 states that it is the responsibility of the routeing domain administrative authority to enforce the uniqueness of the system ID. In cases where a zero configuration system is supplied the system manufacturer MUST install a suitable unique identifier at manufacturing time. One way to achieve this is for the manufacturer to use a unique IEEE MAC address following the allocation procedures normally used in the manufacture of an Ethernet interface. This tosses the issue back into the implementor's lap (which, incidentally, is exactly where I think the problem belongs), and suggests an existing and known solution where a MAC identifier may be allocated for the system itself and used as a global ID to construct the necessary IS-IS System ID. For use in this draft, I would alter the wording slightly to indicate that zero-configuration is strongly preferred for TRILL (as guidance), and that obtaining a suitable identifier is the implementor's responsibility, rather than just saying "in cases where." Would this change fly without breaking consensus? Or do we have to start over? </pre> James Carlson 2011-05-31T17:05:07 http://comments.gmane.org/gmane.ietf.pppext/1136 <pre>Hi All While working with ML-PPP over some time, I have come across some problems which I think should be solved at the protocol level. Please review the abstract below and let me know your valuable opinions: As per existing RFC, following are the key characteristics of LCP negotiation for multi-link parameters: • MRRU option is considered as mandatory option for a link to join a MC/ML-PPP bundle • Endpoint discriminator is optional and can be used to identify different PPP peers • Short-sequence number as an option is negotiated as part of LCP although same value has to be negotiated on all the links Problem that current protocol creates is that it allows a scope for bundle level parameters to be negotiated with different values on different links. This leads to an implementation ambiguity about which values to be chosen for the bundle. Some of the ways applications can implement this choice are: - Choose the negotiated value from the latest link that came - Choose the first value that was negotiated - Choose the one matching operator configuration etc. Is there already a solution to this problem as part of protocol that I am missing? -&gt; Proposed solution Since the bundle level parameters like MRRU &amp; sequence number length are applicable to all bundles in a link, it is better to negotiate them like an NCP after LCP has already been done. So, like other NCP protocols, there can be a new protocol called ML-CP which will configure all bundle level parameters for all the links in the bundle. This will remove the ambiguity about choosing the values of bundle level parameters and also prevent different values being negotiated for same parameter in case of some mis-configuration. However, still there is a need to have some parameter in LCP which determines the bundle association of a link. In order to do that we can use endpoint discriminator as a mandatory option in LCP for links which want to join a bundle. Maintaining backward compatibility with existing implementations might be a challenge, however in this case. However, that can be resolved by including a simple version number option in LCP. Regards Vineet "DISCLAIMER: This message is proprietary to the Aricent Group and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. The Aricent Group accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> Vineet kumar Garg 2011-05-26T09:21:45 http://comments.gmane.org/gmane.ietf.pppext/1134 <pre> The IESG has received a request from the Point-to-Point Protocol Extensions WG (pppext) to consider the following document: - 'PPP TRILL Protocol Control Protocol' &lt;draft-ietf-pppext-trill-protocol-06.txt&gt; as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf&lt; at &gt;ietf.org mailing lists by 2011-06-08. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> The IESG 2011-05-25T16:13:57 http://comments.gmane.org/gmane.ietf.pppext/1128 <pre>I have reviewed this draft. I think it is basically in good shape, but needs to make a few things more explicit &amp; correct small issues. For what it is worth, I'm happy with the resolution of the system ID issue; it really needs to be out of scope and dealt in ISIS WG, if they think its an issue. I'm expecting a new draft version. Then I can start an IETF Last Call. Also, for the record, as James is both the WG chair and the author, I have reviewed the discussion in the mailing list and believe that the Working Group has consensus to move the document forward. Section 2.1: Can you clarify what this actually means. It was not clear (to this reader, at least). Is this where the configuration options would be, if some were defined? But if so, what does LCP code numbers have to do with it? Section 2.2: Please add a reference to the document and Section where these fields are defined. TRILL version of IS-IS, I presume. Please provide a reference to the RFC that specifies the IS-IS payload used in this context. Section 9.3 of [6] seems to talk about something else. If you meant [1] it has no Section 9.3. Please clarify. I think you mean that if the peer is not an RBridge then the negotiation in this specification fails and no TRILL is used for the PPP link. I did not find a specification for the state machine (open/closed) in the draft. Please specify. I think you mean TRILL MTU-probe. Please point to the appropriate section of [1] so that the reader knows for sure which messages you are referring to. Expand the acronym I would make this even clearer -- there's no official status yet for [8]. I'd use this: Resolving that issue is outside the scope of this document. Solutions to this issue may be defined elsewhere in the future, see [8] for an example. Jari _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> Jari Arkko 2011-05-24T10:23:59 http://comments.gmane.org/gmane.ietf.pppext/1122 <pre>New "Intended status", updated with various minor changes, such as Radia's request for a bit more detail of Magic Numbers. Also tossed in a MUST to SHOULD change for Don, and made the probability comparison more explicit. Ready to roll. http://tools.ietf.org/rfcdiff?url2=draft-simpson-isis-ppp-unique-01.txt === A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generation of Unique IS-IS System Identifiers Author(s) : William Allen Simpson Filename : draft-simpson-isis-ppp-unique-01.txt Pages : 8 Date : 2011-05-18 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-simpson-isis-ppp-unique-01.txt _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> William Allen Simpson 2011-05-18T14:22:29 http://comments.gmane.org/gmane.ietf.pppext/1121 <pre>Another update of this draft. Among the changes, the draft now says that it intends "Informational" rather than "Experimental" status, and it has switched to use vendor-specific options rather than a distinct IPCP Option number. While I continue to believe that this is not the right layer at which to do this negotiation, and thus it's still an architectural error, the move to a vendor option alleviates many of my concerns. I think we're just down to the use of the IETF as a vanity press. Perhaps if it must go forward, we can agree on some disclaimer text explaining that it's not the product of this working group and that there are serious reservations concerning its use. </pre> James Carlson 2011-05-17T11:34:25 http://comments.gmane.org/gmane.ietf.pppext/1113 <pre>A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP TRILL Protocol Control Protocol Author(s) : James Carlson Filename : draft-ietf-pppext-trill-protocol-04.txt Pages : 7 Date : 2011-05-09 The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-04.txt _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> internet-drafts< at >ietf.org 2011-05-09T16:02:27 http://comments.gmane.org/gmane.ietf.pppext/1107 <pre>A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP TRILL Protocol Control Protocol Author(s) : J. Carlson Filename : draft-ietf-pppext-trill-protocol-03.txt Pages : 6 Date : 2011-03-30 The Point-to-Point Protocol (PPP) [1] defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> Internet-Drafts< at >ietf.org 2011-03-30T19:45:02 http://comments.gmane.org/gmane.ietf.pppext/1103 <pre>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: &lt;9206292135.AA00620&lt; at &gt;saffron.acc.com&gt; + [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 &amp; Sons, + 1996. ISBN 0-471-11709-9. + [Simpson1992] + Simpson, W., "where are we?", Message to IESG and others, + April 17, 1992. Message-Id: + &lt;269.bsimpson&lt; at &gt;vela.acs.oakland.edu&gt; + [Simpson1993] + Simpson, W., "Re: Simple Multilink Proceedure for PPP - + the document", Message to ietf-ppp and iplpdn mailing + lists, February 21, 1993. Message-Id: + &lt;988.bill.simpson&lt; at &gt;um.cc.umich.edu&gt; 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&lt; at &gt;Gmail.com Simpson expires August 29, 2011 [Page 6] _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> William Allen Simpson 2011-03-30T02:49:13 http://comments.gmane.org/gmane.ietf.pppext/1095 <pre>Sadly, I wasn't paying attention, and didn't notice there was another IETF meeting coming up. So, they won't let me post this draft today. Here it is anyway for your perusal, just in case anybody is interested! === 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 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. 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 William.Allen.Simpson&lt; at &gt;Gmail.com Simpson expires August 17, 2011 [Page 5] _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> William Allen Simpson 2011-03-17T19:24:17 http://comments.gmane.org/gmane.ietf.pppext/1093 <pre>Two new drafts were posted for IPv6CP extensions. The announcements are attached. You can see diffs from the previous version by looking here: http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-requirements-01 http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-extensions-01 </pre> James Carlson 2011-03-14T21:31:29 http://comments.gmane.org/gmane.ietf.pppext/1092 <pre>I see nothing particularly new here -- just a rehash of the existing ability to negotiate NCPs when and where desired -- but since it describes PPP mechanisms directly, I'm forwarding it along to the list. </pre> James Carlson 2011-03-08T15:30:33 http://comments.gmane.org/gmane.ietf.pppext/1091 <pre>This message was somehow lost in the ether. I've contacted ietf-action to see if they can dig up any information. In any event, sorry, Anoop, for the inadvertent delay. </pre> James Carlson 2011-02-07T16:15:57 http://comments.gmane.org/gmane.ietf.pppext/1081 <pre> 3. An implementation that has only PPP links might have no previously configured Media Access Control (MAC) that can function as an IS-IS System ID. In this case, the System ID is formed by adding a randomly generated 14-bit leading number (in place of an OUI) to the link's unique LCP Magic Number. The Magic Number MUST be unique for all links and all known link peers. This pseudo-MAC MUST have both the "locally-assigned" and "broadcast/multicast" (group) bits set to 1; that is, the least significant two bits of the most significant octet are both set to 1. ... Operational Considerations Although the probability of conflict with another IS-IS System ID is minuscule, each implementation MUST have a configuration option to override the System ID. _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> William Allen Simpson 2011-01-27T11:03:45 http://comments.gmane.org/gmane.ietf.pppext/1059 <pre>A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP TRILL Protocol Control Protocol Author(s) : J. Carlson Filename : draft-ietf-pppext-trill-protocol-02.txt Pages : 6 Date : 2011-01-06 The Point-to-Point Protocol (PPP) [1] defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> Internet-Drafts< at >ietf.org 2011-01-06T15:45:01 http://comments.gmane.org/gmane.ietf.pppext/1055 <pre>Hi, I've received a comment about the last figure in Section 2.3 of draft-ietf-trill-rbridge-protocol-16.txt. This figure shows a very high level generic view of a TRILL Data frame being sent over PPP. However, there is a possible problem with that figure. The general form of a TRILL Data frame is Link Header TRILL Header Encapsulated data frame in Ethernet format Link Trailer If the link is Ethernet, the Link Header is an Ethernet Header (destination MAC, source MAC, possible VLAN tag, Ethertype) and the Link Trailer is an Ethernet Trailer, that is, an FCS covering the entire frame. If the link is PPP, then we should have a PPP Header, which is fine and is shown in the figure, but is there a "PPP Trailer"? The figure shows an "Ethernet FCS" which may be wrongly labeled. If there is an FCS there, calculated as Ethernet does, how much of the frame does it cover? In particular, does it cover the PPP Header, in which case I think it should be labeled "PPP FCS"? Or should the convention in PPP be to have an FCS just covering the encapsulated Ethernet frame? In any case, I think a few words about this are needed in the pppext-trill draft... Thanks, Donald =============================  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)  155 Beaver Street  Milford, MA 01757 USA  d3e3e3&lt; at &gt;gmail.com _______________________________________________ Pppext mailing list Pppext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pppext </pre> Donald Eastlake 2011-01-03T17:27:20 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.pppext