From acee.lindem@ericsson.com Mon Sep 2 10:24:03 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF6F11E8132 for ; Mon, 2 Sep 2013 10:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTZb7ZXDkz3K for ; Mon, 2 Sep 2013 10:23:56 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5A011E8130 for ; Mon, 2 Sep 2013 10:23:55 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-7d-5224c9aaa253 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id ED.4F.09414.AA9C4225; Mon, 2 Sep 2013 19:23:54 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Mon, 2 Sep 2013 13:23:53 -0400 From: Acee Lindem To: OSPF List Thread-Topic: RFC 6506Bis - Supporting Authentication Trailer for OSPFv3 Thread-Index: AQHOqAEy4u96D7SYkEyFoJvmvADslQ== Date: Mon, 2 Sep 2013 17:23:53 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470303AE7F@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470303AE7Feusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXSPn+6qkypBBpMmaVjMuXeP1aLl3j12 i3NP5zA6MHu0PtvL6jHl90ZWjyVLfjIFMEdx2aSk5mSWpRbp2yVwZTSu/s5acEug4vvWnywN jPP5uhg5OSQETCT23PzHCGGLSVy4t56ti5GLQ0jgKKNEw6FV7BDOMkaJvrP72EGq2AR0JJ4/ +scMYosIyEosXbKfFaSIWaCRUaL30WNWkISwgLPEs0croIo8JDYcaGCDsPUkDv9YDGazCKhI /OydCVbPK+ArsfjiYiYQmxHojO+n1oDZzALiEreezGeCOE9AYsme88wQtqjEy8f/wHpFgWa2 HTvDDhFXlljyZD8LRG++xJP7Jxgh5gtKnJz5hGUCo8gsJGNnISmbhaQMIq4jsWD3JzYIW1ti 2cLXzDD2mQOPoXqtJbqa9rIjq1nAyLGKkaO0OLUsN93IYBMjMNqOSbDp7mDc89LyEKM0B4uS OO8qvTOBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhlztfOdgpSXJ3lEf/75mVN1qo7NgG2 tUlpzAtfeFx1e+UimRoopvEwNnCDxq8Xr3jS+n9ejDmRfoNvJof7p6DJGQYz9Zey7+NVElV5 n2q3fdmpeaEftpq7B8R/DL11xtV2Du/32Kz4sKgoXZaZqaxMd77HKCvt90vuTLcxlK161vU5 4OL7LiWW4oxEQy3mouJEAB+5/8mEAgAA Cc: Vishwas Manral Subject: [OSPF] RFC 6506Bis - Supporting Authentication Trailer for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 17:24:03 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470303AE7Feusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I have now received review confirmation from every one either involved in e= rrata for RFC 6506 or suggesting minor changes which were accepted. Additio= nally, Sean Turner, Security AD, reviewed the added text discussing the cho= ice of key length. At this time, I'd like to start a 2 week WG last call on= the RFC6506Bis draft. The last call will end at 12:00 AM PDT on September = 17th, 2013. Please review the document and send any comments to the list pr= ior to that time. Here is a URL for your convenience: http://www.ietf.org/id/draft-ietf-ospf-rfc6506bis-00.txt Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE470303AE7Feusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <5451AC05CEF17844813386BA60501966@ericsson.com> Content-Transfer-Encoding: quoted-printable 
All,=20

I have now received review confirmation from every one either involved in e=
rrata for RFC 6506 or suggesting minor changes which were accepted. Additio=
nally, Sean Turner, Security AD, reviewed the added text discussing the cho=
ice of key length. At this time, I'd like to start a 2 week WG last call on=
 the RFC6506Bis draft. The last call will end at 12:00 AM PDT on September =
17th, 2013. Please review the document and send any comments to the list pr=
ior to that time. Here is a URL for your convenience:=20

Thanks,
Acee 
--_000_94A203EA12AECE4BA92D42DBFFE0AE470303AE7Feusaamb101erics_-- From jeff.tantsura@ericsson.com Mon Sep 2 14:57:23 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2983411E8177 for ; Mon, 2 Sep 2013 14:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXJ3mTvMF1i3 for ; Mon, 2 Sep 2013 14:57:17 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2A19711E8175 for ; Mon, 2 Sep 2013 14:57:16 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-d8-522509bcbbe2 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 32.33.03458.CB905225; Mon, 2 Sep 2013 23:57:16 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Mon, 2 Sep 2013 17:57:15 -0400 From: Jeff Tantsura To: Acee Lindem , OSPF List Thread-Topic: [OSPF] RFC 6506Bis - Supporting Authentication Trailer for OSPFv3 Thread-Index: AQHOqAEy4u96D7SYkEyFoJvmvADslZmyzG6A Date: Mon, 2 Sep 2013 21:57:14 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C7483991061A@eusaamb109.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470303AE7F@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C7483991061Aeusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXRPoO4eTtUgg7mXlCxa7t1jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxul/79gKTipWdEyYy9bAOE+2i5GTQ0LAROJA/2E2CFtM4sK9 9UA2F4eQwFFGiQ//prNCOMsYJda+WsUEUsUmYCDx/9txFhBbRMBV4u3TdWDdzAJaEh92bgFq 4OAQFgiQmDY7FcQUEQiUaLldBFFtJHF230JmEJtFQEWi48d+MJtXwFvi1uOP7CA2p4CfxKIt z8FsRqB7vp9awwQxXVzi1pP5TBB3Ckgs2XOeGcIWlXj5+B8riC0qoCfRduwMO0RcWWLJk/0s EL35EiePTmeB2CUocXLmE5YJjKKzkIydhaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48huq1 luic0cSErGYBI8cqRo7S4tSy3HQjw02MwLg6JsHmuINxwSfLQ4zSHCxK4rwb9M4ECgmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamCs/2A90ZHjbcrfVwLOgSWq69kCdaK+FfbYlcjUp8+O3X77 u7LozqK+aQKMl4/+cfv8c7FzNXN41IJG/XkMF/1eRtww4lQ6lhX/Ye/muWt/6efoesVtF/sn bNV8/H+PG5Nj0vbHNs+PM5pcyRJXtv+/7G2qPE+q0gMV2ev/J3Ez/pxXFJCjuUyJpTgj0VCL uag4EQArCspDeQIAAA== Cc: Vishwas Manral Subject: Re: [OSPF] RFC 6506Bis - Supporting Authentication Trailer for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 21:57:23 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C7483991061Aeusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support Cheers, Jeff From: Acee Lindem Lindem III > Date: Monday, September 2, 2013 10:23 AM To: "ospf@ietf.org" > Cc: Vishwas Manral > Subject: [OSPF] RFC 6506Bis - Supporting Authentication Trailer for OSPFv3 All, I have now received review confirmation from every one either involved in e= rrata for RFC 6506 or suggesting minor changes which were accepted. Additio= nally, Sean Turner, Security AD, reviewed the added text discussing the cho= ice of key length. At this time, I'd like to start a 2 week WG last call on= the RFC6506Bis draft. The last call will end at 12:00 AM PDT on September = 17th, 2013. Please review the document and send any comments to the list pr= ior to that time. Here is a URL for your convenience: http://www.ietf.org/id/draft-ietf-ospf-rfc6506bis-00.txt Thanks, Acee --_000_60DEDD93F5E54B4AB55647B8B6C7483991061Aeusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <096AF6C84D2EFE4EA69D787F02EBC173@ericsson.com> Content-Transfer-Encoding: quoted-printable
Yes/support

Cheers,
Jeff

From: Acee Lindem Lindem III <acee.lindem@ericsson.com><= br> Date: Monday, September 2, 2013 10:= 23 AM
To: "ospf@ietf.org" <ospf@i= etf.org>
Cc: Vishwas Manral <vishwas.manral@hp.com>
Subject: [OSPF] RFC 6506Bis - Suppo= rting Authentication Trailer for OSPFv3

All,=20

I have now received review confirmation from every one either involved in e=
rrata for RFC 6506 or suggesting minor changes which were accepted. Additio=
nally, Sean Turner, Security AD, reviewed the added text discussing the cho=
ice of key length. At this time, I'd like to start a 2 week WG last call on=
 the RFC6506Bis draft. The last call will end at 12:00 AM PDT on September =
17th, 2013. Please review the document and send any comments to the list pr=
ior to that time. Here is a URL for your convenience:=20

Thanks,
Acee 
 --_000_60DEDD93F5E54B4AB55647B8B6C7483991061Aeusaamb109ericsso_-- From iesg-secretary@ietf.org Tue Sep 3 08:54:03 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FD321E817F; Tue, 3 Sep 2013 08:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQVZIOGfiFXY; Tue, 3 Sep 2013 08:54:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E8321E8177; Tue, 3 Sep 2013 08:53:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130903155318.30442.24291.idtracker@ietfa.amsl.com> Date: Tue, 03 Sep 2013 08:53:18 -0700 Cc: ospf mailing list , ospf chair , RFC Editor Subject: [OSPF] Document Action: 'Use of OSPF-MDR in Single-Hop Broadcast Networks' to Experimental RFC (draft-ietf-ospf-manet-single-hop-mdr-04.txt) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:54:03 -0000 The IESG has approved the following document: - 'Use of OSPF-MDR in Single-Hop Broadcast Networks' (draft-ietf-ospf-manet-single-hop-mdr-04.txt) as Experimental RFC This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ Technical Summary This draft describes the application of the OSPF MDR mechanisms to single-hop broadcast networks. It also includes simplications for MDR selection and Router-LSA origination on single-hop broadcast networks. Working Group Summary The initial draft was authored about two years ago in response to the OSPF Hybrid Interface draft and OSPF MANET OR draft. There was some discussion between those familiar with OSPF MANET extensions. There has been little WG last call discussion. Consequently, Joe Macker and Tom Henderson were recruited as reviewers based on their MANET knowledge and involvement with the original OSPF MANET work. As updated version was published based this review. Document Quality The document has gone through several WG review cycles and revisions. Comments were received from some WG members. There are no implementations. Personnel Acee Lindem, OSPF WG chair, is the document shepherd and Stewart Bryant is the responsible AD. From xuxiaohu@huawei.com Mon Sep 9 17:59:18 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E1D11E80E8 for ; Mon, 9 Sep 2013 17:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhvAbKkZYl-M for ; Mon, 9 Sep 2013 17:59:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D3B5511E80D1 for ; Mon, 9 Sep 2013 17:59:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AXC97403; Tue, 10 Sep 2013 00:59:13 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 01:59:07 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 01:59:12 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0146.000; Tue, 10 Sep 2013 08:59:06 +0800 From: Xuxiaohu To: "ospf@ietf.org" Thread-Topic: New Version Notification for draft-xu-mpls-el-capability-signaling-igp-00.txt Thread-Index: AQHOqpxBgOQ7W0a3H0y3V2f13IPaSpm+KYCwgAADBCA= Date: Tue, 10 Sep 2013 00:59:05 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820CC37@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [OSPF] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?=09draft-xu-mpls-el-capability-signaling-igp-00=2Etxt?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 00:59:18 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IFh1eGlhb2h1DQo+IOWP kemAgeaXtumXtDogMjAxM+W5tDnmnIgxMOaXpSA4OjU2DQo+IOaUtuS7tuS6ujogbXBsc0BpZXRm Lm9yZzsgaXNpcy13Z0BpZXRmLm9yZyBsaXN0OyAnb3NwZkBpZXRmLm9yZycNCj4g5Li76aKYOiBm d2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQteHUtbXBscy1lbC1jYXBh YmlsaXR5LXNpZ25hbGluZy1pZ3AtMDAudHh0DQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBUaGUgZm9s bG93aW5nIGRyYWZ0IGRlZmluZXMgYSBtZWNoYW5pc20gdG8gc2lnbmFsIHRoZSBFbnRyb3B5IExh YmVsIENhcGFiaWxpdHkNCj4gKEVMQykgdXNpbmcgSVNJUyBhbmQgT1NQRiwgd2hpY2ggaXMgYXBw bGljYWJsZSBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgbGFiZWwNCj4gYWR2ZXJ0aXNlbWVudCBpcyBh bHNvDQo+IGRvbmUgdmlhIHRoYXQgSUdQLg0KPiANCj4gQW55IGNvbW1lbnRzIGFuZCBzdWdnZXN0 aW9ucyBhcmUgd2VsY29tZS4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+IA0KPiA+ IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4gPiDlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gPiDlj5HpgIHml7bp l7Q6IDIwMTPlubQ55pyINuaXpSA4OjU5DQo+ID4g5pS25Lu25Lq6OiBDbGFyZW5jZSBGaWxzZmls czsgU3JpZ2FuZXNoIEtpbmk7IFh1eGlhb2h1OyBTaXZhIFNpdmFiYWxhbjsgWHV4aWFvaHUNCj4g PiDkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiBkcmFmdC14dS1tcGxz LWVsLWNhcGFiaWxpdHktc2lnbmFsaW5nLWlncC0wMC50eHQNCj4gPg0KPiA+DQo+ID4gQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXh1LW1wbHMtZWwtY2FwYWJpbGl0eS1zaWduYWxpbmctaWdw LTAwLnR4dA0KPiA+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2h1IFh1 IGFuZCBwb3N0ZWQgdG8gdGhlDQo+ID4gSUVURiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gRmlsZW5h bWU6CSBkcmFmdC14dS1tcGxzLWVsLWNhcGFiaWxpdHktc2lnbmFsaW5nLWlncA0KPiA+IFJldmlz aW9uOgkgMDANCj4gPiBUaXRsZToJCSBTaWduYWxpbmcgRW50cm9weSBMYWJlbCBDYXBhYmlsaXR5 IFVzaW5nIEludGVyaW9yIEdhdGV3YXkNCj4gUHJvdG9jb2xzDQo+ID4gQ3JlYXRpb24gZGF0ZToJ IDIwMTMtMDktMDYNCj4gPiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gPiBOdW1i ZXIgb2YgcGFnZXM6IDUNCj4gPiBVUkw6DQo+ID4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQteHUtbXBscy1lbC1jYXBhYmlsaXR5LXNpZ25hbGluZy1pZ3AtMDAu dA0KPiA+IHh0DQo+ID4gU3RhdHVzOg0KPiA+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQteHUtbXBscy1lbC1jYXBhYmlsaXR5LXNpZ25hbGluZy1pZ3ANCj4gPiBIdG1saXpl ZDoNCj4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1tcGxzLWVsLWNhcGFi aWxpdHktc2lnbmFsaW5nLWlncC0wMA0KPiA+DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBN dWx0aSBQcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIGhhcyBkZWZpbmVkIGEgbWVjaGFu aXNtIHRvIGxvYWQNCj4gPiAgICBiYWxhbmNlIHRyYWZmaWMgZmxvd3MgdXNpbmcgRW50cm9weSBM YWJlbHMgKEVMKS4gIEFuIExTUiBpbnNlcnRzIHRoZQ0KPiA+ICAgIEVMIEluZGljYXRvciBhbmQg dGhlIEVMIGxhYmVsIG9ubHkgaWYgdGhlIExTUiB0aGF0IHBvcHMgdGhlbSBoYXMgdGhlDQo+ID4g ICAgY2FwYWJpbGl0eSBvZiBwcm9jZXNzaW5nIHRoZW0uICBUaGlzIGRyYWZ0IGRlZmluZXMgYSBt ZWNoYW5pc20gdG8NCj4gPiAgICBzaWduYWwgdGhhdCBjYXBhYmlsaXR5IHVzaW5nIGxpbmsgc3Rh dGUgSW50ZXJpb3IgR2F0ZXdheSBQcm90b2NvbHMNCj4gPiAgICAoSUdQKS4gIFRoaXMgbWVjaGFu aXNtIGlzIHVzZWZ1bCB3aGVuIHRoZSBsYWJlbCBhZHZlcnRpc2VtZW50IGlzIGFsc28NCj4gPiAg ICBkb25lIHZpYSB0aGF0IElHUC4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24NCj4gPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+DQo+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From wwwrun@rfc-editor.org Tue Sep 10 17:31:56 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF88C11E8131; Tue, 10 Sep 2013 17:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.233 X-Spam-Level: X-Spam-Status: No, score=-101.233 tagged_above=-999 required=5 tests=[AWL=1.367, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtEMG0my65k3; Tue, 10 Sep 2013 17:31:56 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 178BE11E80DF; Tue, 10 Sep 2013 17:31:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EC57E8E016; Tue, 10 Sep 2013 17:25:55 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130911002555.EC57E8E016@rfc-editor.org> Date: Tue, 10 Sep 2013 17:25:55 -0700 (PDT) Cc: drafts-update-ref@iana.org, ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 6987 on OSPF Stub Router Advertisement X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 00:31:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6987 Title: OSPF Stub Router Advertisement Author: A. Retana, L. Nguyen, A. Zinin, R. White, D. McPherson Status: Informational Stream: IETF Date: September 2013 Mailbox: aretana@cisco.com, lhnguyen@cisco.com, alex.zinin@gmail.com, Russ.White@vce.com, dmcpherson@verisign.com Pages: 7 Characters: 10890 Obsoletes: RFC 3137 I-D Tag: draft-ietf-ospf-rfc3137bis-04.txt URL: http://www.rfc-editor.org/rfc/rfc6987.txt This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router. This document obsoletes RFC 3137. This document is a product of the Open Shortest Path First IGP Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From acee.lindem@ericsson.com Tue Sep 10 17:54:36 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2A021F997B for ; Tue, 10 Sep 2013 17:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3LhE8RbJ1Pi for ; Tue, 10 Sep 2013 17:54:31 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 757EB21E805F for ; Tue, 10 Sep 2013 17:54:30 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-3a-522fbf45639e Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F6.47.03458.54FBF225; Wed, 11 Sep 2013 02:54:30 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Tue, 10 Sep 2013 20:54:29 -0400 From: Acee Lindem To: OSPF List Thread-Topic: RFC 6987 on OSPF Stub Router Advertisement Thread-Index: AQHOroZjV/rjHWdtc0atcgGJXEPVfA== Date: Wed, 11 Sep 2013 00:54:28 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4703048B75@eusaamb101.ericsson.se> References: <20130911002555.EC57E8E016@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4703048B75eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPgq7bfv0gg5d/mSxa7t1jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxutbK5kKjvlXHGvbzNLAeMa1i5GTQ0LAROL/0wMsELaYxIV7 69m6GLk4hASOMkpM2XGcCcJZzijRcPQoG0gVm4COxPNH/5hBbBEBWYmlS/azdjFycAgLWEgc 7PeBCFtIHH71jBHC1pM4v38iWCuLgKrErd4lYHFeAV8g+xhYq5CAmcSR494gYUagG76fWsME YjMLiEvcejKfCeI2AYkle84zQ9iiEi8f/2OFsJUlljzZzwJRny8xeddKZojxghInZz5hmcAo PAvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGOgXg4g21ri9Xl2ZCULGDlWMXKUFqeW 5aYbGW5iBEbJMQk2xx2MCz5ZHmKU5mBREufdoHcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAMji4LJ8eWXxPXC3mlf9dIyjDZY6R8ZM81v59eP/dHzXvOdiRWblRFdNTs1apPrHFnXp7lf xTQWnXvGfc05w9pqa14NS865e9PelLNsvpspcEH4NuPf/duVvmic2/ufN8c3wslIZtkaKXOH CXsTIyTehhUlsrwVldxfoedSGLG+50WalnLgu3VKLMUZiYZazEXFiQDpezjMYAIAAA== Subject: [OSPF] Fwd: RFC 6987 on OSPF Stub Router Advertisement X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 00:54:36 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE4703048B75eusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Happy Birthday to Alex Zinin who managed to get an RFC published on the sam= e day! Begin forwarded message: From: > Date: September 10, 2013 8:25:55 PM EDT To: >, > Cc: >, >, > Subject: RFC 6987 on OSPF Stub Router Advertisement Reply-To: > A new Request for Comments is now available in online RFC libraries. RFC 6987 Title: OSPF Stub Router Advertisement Author: A. Retana, L. Nguyen, A. Zinin, R. White, D. McPherson Status: Informational Stream: IETF Date: September 2013 Mailbox: aretana@cisco.com, lhnguyen@cisco.com, alex.zinin@gmail.com, Russ.White@vce.com, dmcpherson@verisign.com Pages: 7 Characters: 10890 Obsoletes: RFC 3137 I-D Tag: draft-ietf-ospf-rfc3137bis-04.txt URL: http://www.rfc-editor.org/rfc/rfc6987.txt This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router. This document obsoletes RFC 3137. This document is a product of the Open Shortest Path First IGP Working Grou= p of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_sear= ch.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC --_000_94A203EA12AECE4BA92D42DBFFE0AE4703048B75eusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <66A836009629C3408864A690D232ACC7@ericsson.com> Content-Transfer-Encoding: quoted-printable Happy Birthday to Alex Zinin who managed to get an RFC published on the sam= e day! 

Begin forwarded message:

From: <<= a href=3D"mailto:rfc-editor@rfc-editor.org">rfc-editor@rfc-editor.org&g= t;
Date: Septe= mber 10, 2013 8:25:55 PM EDT
To: <<= a href=3D"mailto:ietf-announce@ietf.org">ietf-announce@ietf.org>, &l= t;rfc-dist@rfc-editor.org>= ;
Cc: <<= a href=3D"mailto:drafts-update-ref@iana.org">drafts-update-ref@iana.org= >, <ospf@ietf.org>, <rfc-editor@rfc-editor.org>
Subject: RF= C 6987 on OSPF Stub Router Advertisement
Reply-To: <<= a href=3D"mailto:ietf@ietf.org">ietf@ietf.org>

A new Request for Comments is now available in online RFC libraries.

       RFC 6987

       Title:     &n= bsp;OSPF Stub Router Advertisement
       Author:     A= . Retana, L. Nguyen,
            &nb= sp;      A. Zinin, R. White,
            &nb= sp;      D. McPherson
       Status:     I= nformational
       Stream:     I= ETF
       Date:     &nb= sp; September 2013
       Mailbox:    aretana@cisco.com,
            &nb= sp;      lhnguyen@cisco.com,
            &nb= sp;      alex.zinin@gmail.com,
            &nb= sp;      Russ.White@vce.com,
            &nb= sp;      dmcpherson@verisign.com
       Pages:     &n= bsp;7
       Characters: 10890
       Obsoletes:  RFC 3137

       I-D Tag:    draft-= ietf-ospf-rfc3137bis-04.txt

       URL:     &nbs= p;  http://= www.rfc-editor.org/rfc/rfc6987.txt

This document describes a backward-compatible technique that may be
used by OSPF (Open Shortest Path First) implementations to advertise
a router's unavailability to forward transit traffic or to lower the
preference level for the paths through such a router.

This document obsoletes RFC 3137.

This document is a product of the Open Shortest Path First IGP Working Grou= p of the IETF.


INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
 http:/= /www.ietf.org/mailman/listinfo/ietf-announce
 h= ttp://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see ht= tp://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



--_000_94A203EA12AECE4BA92D42DBFFE0AE4703048B75eusaamb101erics_-- From russw@riw.us Tue Sep 10 20:13:32 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675A021F9F8F for ; Tue, 10 Sep 2013 20:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxEbgSBK0ifG for ; Tue, 10 Sep 2013 20:13:26 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8243A21F9F96 for ; Tue, 10 Sep 2013 20:13:26 -0700 (PDT) Received: from [12.207.21.2] (helo=RussPC) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1VJart-0002OX-1r; Tue, 10 Sep 2013 20:13:25 -0700 From: "Russ White" To: "'Acee Lindem'" , "'OSPF List'" References: <20130911002555.EC57E8E016@rfc-editor.org> <94A203EA12AECE4BA92D42DBFFE0AE4703048B75@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4703048B75@eusaamb101.ericsson.se> Date: Tue, 10 Sep 2013 23:13:26 -0400 Message-ID: <005001ceae9c$e24dbe00$a6e93a00$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFxZnEpArswgRfDkXbqtYgK+3Ks0gJOiEhymmf4OlA= Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [OSPF] Fwd: RFC 6987 on OSPF Stub Router Advertisement X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 03:13:32 -0000 > Happy Birthday to Alex Zinin who managed to get an RFC published on the > same day! Is this the best birthday present ever, or... the geekiest? What I want to know is how he arranged it, and if we should make a call to the Internet Hall of Fame... :-) Russ From curtis@ipv6.occnc.com Wed Sep 11 08:04:49 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADBA21E8121 for ; Wed, 11 Sep 2013 08:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xroffyw937id for ; Wed, 11 Sep 2013 08:04:41 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id B99CF11E81BB for ; Wed, 11 Sep 2013 08:03:45 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r8BF2B2U005856; Wed, 11 Sep 2013 11:02:11 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201309111502.r8BF2B2U005856@gateway1.orleans.occnc.com> To: Xuxiaohu From: Curtis Villamizar In-reply-to: Your message of "Tue, 10 Sep 2013 00:59:05 -0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820CC37@NKGEML512-MBS.china.huawei.com> Date: Wed, 11 Sep 2013 11:02:11 -0400 Cc: "ospf@ietf.org" Subject: Re: [OSPF] : New Version Notification for draft-xu-mpls-el-capability-signaling-igp-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 15:04:50 -0000 In message <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820CC37@NKGEML512-MBS.china.huawei.com> Xuxiaohu writes: > Hi all, > > The following draft defines a mechanism to signal the Entropy Label > Capability (ELC) using ISIS and OSPF, which is applicable in the > case where the label advertisement is also done via that IGP. > > Any comments and suggestions are welcome. > > Best regards, > Xiaohu Xiaohu, This is a short document and it uses the OSPF Router Information (RI) Opaque LSA defined in [RFC4970] and IS-IS Router CAPABILITY TLV defined in [RFC4971]. That won't work if some of the interfaces are ELC and others are not. This would be a common case in transition or after transition if a spare card was not ELC but otherwise useable and was needed after a card failure. ELC must be on a per interface basis. While you are at it, please also consider including the following 0) whether the interface can terminate an LSP with ELI and EL (aka ELC, what you planned to cover), 1) whether the interface can find an ELI and EL in the label stack and make use of it, 2) at what maximum depth can the entropy occur (maybe 0 for more than 255 or more than 65535 which would be absurd), 3) whether the search for entropy is terminated when the EL is encountered (RFC6790 says "SHOULD" and some people including me think that should have been a "MUST"), 4) whether reserved labels are ignored (may matter for GAL, therefore MPLS-TP protected by EL), 5) whether reserved extended labels are ignored, 6) whether the interface will look below the stack for entropy (ie: looks for 4 or 6 in first payload nibble and needs PWE CW if payload is not IP). Note that for MPLS-TP to be carried protected by ELI and EL, #1 plus either #3 or #4 (or both) must be true. Also note that #4 and #5 can be true even if #0 and #1 are not true and #4 would be sufficient for MPLS-TP with no labels under the stack. These would be better in a bit map in one TLV rather than one TLV each (though #2 needs an integer). Curtis From manav.bhatia@alcatel-lucent.com Wed Sep 11 20:43:01 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC4721E8124 for ; Wed, 11 Sep 2013 20:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9Ol9ipIho9R for ; Wed, 11 Sep 2013 20:42:45 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id AE07521E8122 for ; Wed, 11 Sep 2013 20:42:45 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r8C3gfjK017820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Sep 2013 22:42:41 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r8C3gchT019090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Sep 2013 23:42:40 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 11 Sep 2013 23:42:39 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Thu, 12 Sep 2013 11:42:36 +0800 From: "Bhatia, Manav (Manav)" To: Gabi Nakibly , Acee Lindem Thread-Topic: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) Thread-Index: AQHOlsgl0FQ/Zi+/Tk+kM9fPB35RJJnBpIjg Date: Thu, 12 Sep 2013 03:42:36 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> In-Reply-To: <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 03:43:01 -0000 Hi Gabi, [clipped] > Nonetheless, I am sure that there are more OSPF vendors out=20 > there that are still vulnerable to the attack and do not=20 > check for this. Moreover, since this check is not part of the=20 > standard, in most likelihood future OSPF implementations will=20 > also be vulnerable. >=20 [clipped] >=20 > I am willing to write a draft describing this mitigation=20 > measure. I would appreciate the list's thoughts on this. I think it's a good idea to write a draft that describes the attack and wha= t implementations MUST do to avoid it.=20 Cheers, Manav >=20 > Gabi >=20 > ----- Original Message ----- > > From: Yi Yang (yiya) > > To: Gabi Nakibly ; Acee Lindem=20 > > ; David Lamparter=20 > ; Glen=20 > > Kent > > Cc: "ospf@ietf.org" > > Sent: Friday, August 9, 2013 4:37 AM > > Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the=20 > > Routing Table Attack) > >=20 > > I would think such an attack can be categorized as=20 > "overclaiming", as=20 > > defined at=20 > http://tools.ietf.org/html/rfc4593#section-4.5.1.1. In this=20 > > case, an attacker claims a resource (link state ID) which does not=20 > > belong to it. > >=20 > > While it might be challenging to defense overclaiming in=20 > some cases,=20 > > it's not that hard to recognize the attack in this case. As pointed=20 > > out by David and Acee, such LSAs should be considered as=20 > malformatted=20 > > as they have unmatched Advertising Router and Link State ID=20 > and can be=20 > > dropped. A more challenging example of overclaiming is the attacker=20 > > simply advertises a bunch of prefixes that are not really=20 > attached on itself. > >=20 > > Yi > > =A0=20 > >=20 > > On 8/5/13 5:03 PM, "Gabi Nakibly" wrote: > >=20 > >> Hi all, > >> My name is Gabi. I am the researcher who presented the new=20 > attack at=20 > >> Black Hat last week. I have noticed the discussion on the=20 > list and I=20 > >> would be happy to try to clarify how the attack is different from=20 > >> known ones. > >> Indeed the attack assumes that the attacker is an insider, meaning=20 > >> that the attacker has already gained control of one of the router=20 > >> within the AS. I agree 100% that once an attacker is an insider he=20 > >> can already do all sorts of attacks that can harm the network and=20 > >> indeed a few past works have already reported on this.=20 > Nonetheless,=A0=20 > >> the crux of the new attack, as Acee has already pointed=20 > out, is that=20 > >> an attacker is now able to falsify an LSA on behalf of=20 > another router=20 > >> while evading the fight-back mechanism. This new=20 > capability allows an=20 > >> attacker to > >> *persistently* and *stealthily* subvert the LSA DB of=20 > other routers=20 > >> that install the false LSA and thereby altering their=20 > routing tables.=20 > >> This gives rise to a new class of attacks that in my=20 > opinion have not=20 > >> existed before and, in many times, are more desirable for=20 > an attacker=20 > >> (due to their stealth and persistence). > >> To my best knowledge, no other general technique to=20 > stealthily evade=20 > >> fight back is known. The only general attack technique to=20 > evade fight=20 > >> back is periodic injection (flooding false LSAs at a rate higher=20 > >> thanone every MinLSInterval)=A0 presented in=20 > >> http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.txt=20 > in Section=20 > >> 4.1.3.1. However,=A0 using such technique the attack is=20 > hardly stealthy. > >>=20 > >> BTW, I have also presented in the past another general=20 > technique to=20 > >> evade fight back called 'Disguised LSA'. It is described in=20 > >>=20 > https://www.cs.technion.ac.il/people/gnakibly/online-publications/Per > >> siste > >> ntOSPF.pdf in Section 4.2. > >>=20 > >> I would appreciate your continued feedback on the new attack. > >>=20 > >> Thanks, > >> Gabi > >>=20 > >>> ________________________________ > >>>=A0=A0From: Acee Lindem > >>> To: David Lamparter ; Glen Kent =20 > >>> > >>> Cc: "ospf@ietf.org" > >>> Sent: Monday, August 5, 2013 5:28 AM > >>> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF -=20 > Owning the =20 > >>>Routing Table Attack) > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> On 8/4/13 6:06 AM, "David Lamparter"=20 > > wrote: > >>>=20 > >>>> On Fri, Aug 02, 2013 at 10:11:01PM +0530, Glen Kent wrote: > >>>>>=A0=A0Does anybody have details on what this OSPF vulnerability is? > >>>>>=20 > >>>>>=A0=A0https://www.blackhat.com/us-13/briefings.html#Nakibly > >>>>=20 > >>>> As people may have noticed by now (the embargo on=20 > providing details > > has > >>>> expired as the talk was presented), this issue consists of Router > > LSAs > >>>> where the Router ID is different from the Link State ID.=A0 > As such, > > this > >>>> attack is implementable from any router in an OSPF area=20 > against any=20 > >>>> other router in the OSPF. > >>>>=20 > >>>> (Quite honestly, IMHO this is seriously far fetched.=A0 If your > > control > >>>> plane got compromised this far you have other problems.) > >>>=20 > >>> I agree that once the OSPF control plane is open, you are=20 > >>> susceptible to many attacks. However, this attack is a bit more=20 > >>> insidious than most since the actual OSPF router corresponding to=20 > >>> the link state ID will most likely not recognize the LSA as=20 > >>> self-originated and re-originate a more recent version when the=20 > >>> malformed one is received. Hence, the malicious LSA > > will > >>> remain in the routing domain and, depending upon the OSPF > > implementation, > >>> could result in traffic being redirected. > >>>=20 > >>>>=20 > >>>> While Quagga is unaffected by this, we've implemented a > > warning.=A0 We're > >>>> also considering dropping the LSA outright, but I'm somewhat > > split on > >>>> that (tilted towards dropping).=A0 I'd be interested if the WG has=20 > >>>> comments on that? > >>>=20 > >>> I can't speak for the WG but my implementation will skip=20 > the LSA in > > the > >>> Link-State Update packet. > >>>=20 > >>> Thanks, > >>> Acee > >>>=20 > >>>=20 > >>>>=20 > >>>>=20 > >>>> -David > >>>> _______________________________________________ > >>>> OSPF mailing list > >>>> OSPF@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ospf > >>>=20 > >>> _______________________________________________ > >>> OSPF mailing list > >>> OSPF@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ospf > >>>=20 > >>>=20 > >>>=20 > >> _______________________________________________ > >> OSPF mailing list > >> OSPF@ietf.org > >> https://www.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > = From asmirnov@cisco.com Thu Sep 12 04:16:39 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A0C21E813E for ; Thu, 12 Sep 2013 04:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F21M8txrdOrq for ; Thu, 12 Sep 2013 04:16:34 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA6521E81DE for ; Thu, 12 Sep 2013 04:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2029; q=dns/txt; s=iport; t=1378984594; x=1380194194; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4Bmosg1YkExD1YULLymME9wG27iZbm67Vlze1nf4nV4=; b=hGeeM9EeoOBuD9bfC7ludo0jhbyWhzcocCZ3SB0l9nvbEFnyHtktuAiL OTBdtTzLMt5beWjIKbqspsuTKrGDjL36YyBwN0gggO3fWmjvsEFaukd52 SYgDAb0DiSxjka+90WeTDuRnXLOlIJFcC196ifXkEGhaRw5E8QqnEjHUg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAEWiMVKQ/khL/2dsb2JhbABbgwe+bIJ0gRsWdIIlAQEBBDhAARALGAkWDwkDAgECAUUGDQEHAQGHfrwejiyBPweEHQOXeZFygWWBPzqBLA X-IronPort-AV: E=Sophos;i="4.90,890,1371081600"; d="scan'208";a="17958495" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 12 Sep 2013 11:16:30 +0000 Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8CBGSuo012241; Thu, 12 Sep 2013 11:16:28 GMT Message-ID: <5231A28C.5030102@cisco.com> Date: Thu, 12 Sep 2013 13:16:28 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 11:16:39 -0000 If attacker has joined flooding domain and can inject an LSA into LSDB then it can screw up routing in the domain. Methods such as pretending being an ABR/ASBR and advertise destinations with good metric are almost impossible to combat once authentication barrier is penetrated. This particular vulnerability allows attacker to bring network down in style but if this vulnerability is not present in the particular network then attacker will simply resort to other numerous possibilities to affect routing via LSA injection. If attacker can inject LSA into LSDB then your network is at his mercy. Give or take one particular method is a detail. So IMO we don't need a draft on this particular vulnerability. It might be of some limited interest to document all known methods to exploit LSA injection which would include this vulnerability but what value would this RFC bring? Such methods are regularly published in academic literature since 90-th. IMO we need good (reliable, secure, manageable etc) methods of authenticating adjacencies. KARP group is working on that. We *might* benefit from a work on mechanism to prevent any router to originate reachable LSA on behalf of any other router (kind of LSA signing). But work on what will go wrong when intended security barriers are broken IMO is not needed. Anton On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote: > Hi Gabi, > > [clipped] > >> Nonetheless, I am sure that there are more OSPF vendors out >> there that are still vulnerable to the attack and do not >> check for this. Moreover, since this check is not part of the >> standard, in most likelihood future OSPF implementations will >> also be vulnerable. >> > [clipped] > >> I am willing to write a draft describing this mitigation >> measure. I would appreciate the list's thoughts on this. > I think it's a good idea to write a draft that describes the attack and what implementations MUST do to avoid it. > > Cheers, Manav > From prz@mail.zeta2.ch Thu Sep 12 04:46:48 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5154811E8222 for ; Thu, 12 Sep 2013 04:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ydDjgiHsVuB for ; Thu, 12 Sep 2013 04:46:43 -0700 (PDT) Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id D882A11E8218 for ; Thu, 12 Sep 2013 04:46:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r8CBkfsd032269 for ; Thu, 12 Sep 2013 13:46:41 +0200 X-Virus-Scanned: amavisd-new at zeta2.ch Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CIrhIeCNoZWd for ; Thu, 12 Sep 2013 13:46:39 +0200 (CEST) Received: from prz-workstation.zeta2.ch (prz-workstation.zeta2.ch [192.168.1.51]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r8CBkY9L032263 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 12 Sep 2013 13:46:35 +0200 Message-ID: <5231A998.1070005@zeta2.ch> Date: Thu, 12 Sep 2013 13:46:32 +0200 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: ospf@ietf.org References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5231A28C.5030102@cisco.com> In-Reply-To: <5231A28C.5030102@cisco.com> Content-Type: multipart/mixed; boundary="------------080604060505050709070702" Subject: Re: [OSPF] Dropping malformed LSAs X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 11:46:48 -0000 This is a multi-part message in MIME format. --------------080604060505050709070702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/12/2013 01:16 PM, Anton Smirnov wrote: > If attacker has joined flooding domain and can inject an LSA into > LSDB then it can screw up routing in the domain. Methods such as > pretending being an ABR/ASBR and advertise destinations with good > metric are almost impossible to combat once authentication barrier is > penetrated. > This particular vulnerability allows attacker to bring network down > in style but if this vulnerability is not present in the particular > network then attacker will simply resort to other numerous > possibilities to affect routing via LSA injection. If attacker can > inject LSA into LSDB then your network is at his mercy. Give or take > one particular method is a detail. > So IMO we don't need a draft on this particular vulnerability. It > might be of some limited interest to document all known methods to > exploit LSA injection which would include this vulnerability but what > value would this RFC bring? Such methods are regularly published in > academic literature since 90-th. > > IMO we need good (reliable, secure, manageable etc) methods of > authenticating adjacencies. KARP group is working on that. We *might* > benefit from a work on mechanism to prevent any router to originate > reachable LSA on behalf of any other router (kind of LSA signing). But > work on what will go wrong when intended security barriers are broken > IMO is not needed. > > Anton Anton, 'securing an adjacency' is ok a step but it will not give you what people seem to look for here. Once you have that you start to talk about the threat models where an adjacency can be compromised or an LSA be injected by some nefarious means. So first thing first: What's the threat model here ? blackhats getting to phy links ? blackhats being able to fake adjacencies ? blackhats being in possesions of PKAs to fake their way into forming secure adjacencies with other people ? blackhats compromising router configurations ? blackhats spoofing end-system addresses to make routers advertise their /32 reachability ? All vastly different things & attacks. So, without a threat model first of all those security discussion tend to change the target while the hunt is ongoing. As it already does, it started from simple attack I-claim-to-be-someone-else attack easily mounted & defeated and talks here now about harder things (reachability attacks, those actually need end-system adjacencies secured as well, hard stuff & not in Internet routing architecture much @ all normally). The thing that holds for the kind of threats this discussion started on quite well is a chain-of-trust security where you basically have to assure not only that an LSP/LSU has been originated by the person claiming to be the originator but as well that all the flooding has happened along trust-of-chain (to prevent .e.g. replay attacks by someone injecting into a link [without an adjacency, not unlikely on ether e.g.]). Techniques for that are known and not that expensive computationally but it is a non-negligible amounts of work involved in such an undertaking. That better be on workgroup charter, requirements docs then ;-) If links to paper, previous art on that are desired, pls ping me, I'll provide --- tony --------------080604060505050709070702 Content-Type: text/x-vcard; charset=utf-8; name="prz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="prz.vcf" begin:vcard fn:A. Przygienda n:Przygienda;A. org:Zeta2 GmbH adr:;;Via Tersaggio 20;Comano;;6949;Switzerland email;internet:prz@zeta2.ch title:Dr. tel;work:+41919402767 tel;fax:+41919402768 tel;cell:+41792985900 x-mozilla-html:TRUE url:http://www.zeta2.ch version:2.1 end:vcard --------------080604060505050709070702-- From manav.bhatia@alcatel-lucent.com Thu Sep 12 07:40:28 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7712011E81A0 for ; Thu, 12 Sep 2013 07:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QELO2BYECEzA for ; Thu, 12 Sep 2013 07:40:22 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id B6D0A11E81AB for ; Thu, 12 Sep 2013 07:40:22 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r8CEeF7F022535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Sep 2013 09:40:16 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r8CEeEtN021722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 10:40:14 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 12 Sep 2013 10:40:14 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Thu, 12 Sep 2013 22:40:11 +0800 From: "Bhatia, Manav (Manav)" To: Anton Smirnov Thread-Topic: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) Thread-Index: AQHOr6mG0FQ/Zi+/Tk+kM9fPB35RJJnCKoRQ Date: Thu, 12 Sep 2013 14:40:10 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E4B4924@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5231A28C.5030102@cisco.com> In-Reply-To: <5231A28C.5030102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 14:40:28 -0000 Anton, I understand that once the attacker can insert LSAs in the flooding domain = then there are several things that can be done. However, in most cases the = attacks can be easily identified and a corrective action can be easily take= n. In this particular case, the attack is a little more insidious and its n= ot straight forward catching the erring LSA. Since its something that's missing in rfc 2328 we will keep having newer im= plementations that will carry this bug. A short one page RFC that updates 2= 328 imo would do no harm. Do you see any issue in publishing such an RFC? I have written a short post on what the issue in 2328 is and how it can be = exploited to launch an attack. http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerabil= ity-exposed-by-black-hat/ Cheers, Manav > -----Original Message----- > From: Anton Smirnov [mailto:asmirnov@cisco.com]=20 > Sent: Thursday, September 12, 2013 4:46 PM > To: Bhatia, Manav (Manav) > Cc: Gabi Nakibly; Acee Lindem; ospf@ietf.org > Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF -=20 > Owning the Routing Table Attack) >=20 > If attacker has joined flooding domain and can inject an=20 > LSA into LSDB then it can screw up routing in the domain.=20 > Methods such as pretending being an ABR/ASBR and advertise=20 > destinations with good metric are almost impossible to combat=20 > once authentication barrier is penetrated. > This particular vulnerability allows attacker to bring=20 > network down in style but if this vulnerability is not=20 > present in the particular network then attacker will simply=20 > resort to other numerous possibilities to affect routing via=20 > LSA injection. If attacker can inject LSA into LSDB then your=20 > network is at his mercy. Give or take one particular method=20 > is a detail. > So IMO we don't need a draft on this particular=20 > vulnerability. It might be of some limited interest to=20 > document all known methods to exploit LSA injection which=20 > would include this vulnerability but what value would this=20 > RFC bring? Such methods are regularly published in academic=20 > literature since 90-th. >=20 > IMO we need good (reliable, secure, manageable etc)=20 > methods of authenticating adjacencies. KARP group is working=20 > on that. We *might* benefit from a work on mechanism to=20 > prevent any router to originate reachable LSA on behalf of=20 > any other router (kind of LSA signing). But work on what will=20 > go wrong when intended security barriers are broken IMO is not needed. >=20 > Anton >=20 >=20 >=20 > On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote: > > Hi Gabi, > > > > [clipped] > > > >> Nonetheless, I am sure that there are more OSPF vendors out there=20 > >> that are still vulnerable to the attack and do not check for this.=20 > >> Moreover, since this check is not part of the standard, in most=20 > >> likelihood future OSPF implementations will also be vulnerable. > >> > > [clipped] > > > >> I am willing to write a draft describing this mitigation=20 > measure. I=20 > >> would appreciate the list's thoughts on this. > > I think it's a good idea to write a draft that describes=20 > the attack and what implementations MUST do to avoid it. > > > > Cheers, Manav > > >=20 > = From acee@lindem.com Thu Sep 12 08:00:58 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881E811E8260 for ; Thu, 12 Sep 2013 08:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPJMuQaOSFHG for ; Thu, 12 Sep 2013 08:00:17 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id BA64A21E80F0 for ; Thu, 12 Sep 2013 07:59:35 -0700 (PDT) X-Authority-Analysis: v=2.0 cv=PogRnnw3 c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=x7FEv9pE1mkA:10 a=cv6AbCrYKhYA:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=QYaTxUjTAAAA:8 a=KGjhK52YXX0A:10 a=kg5FYR9m7LsA:10 a=tJDDVEC1AAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=TQmXhA5hi5FoVrpQDuUA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=C2g1Hp6idNFTy4K9KrF8yg==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 65.190.0.120 Received: from [65.190.0.120] ([65.190.0.120:51337] helo=[192.168.1.106]) by cdptpa-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 24/DC-02184-1D6D1325; Thu, 12 Sep 2013 14:59:29 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4B4924@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Thu, 12 Sep 2013 10:59:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F1F84B6-9A14-4C6E-84C3-2D2A26754C7E@lindem.com> References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5231A28C.5030102@cisco.com> <20211F91F544D247976D84C5D778A4C32E4B4924@SG70YWXCHMBA05.zap.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1085) Cc: "ospf@ietf.org" Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:00:58 -0000 Manav -=20 On Sep 12, 2013, at 10:40 AM, Bhatia, Manav (Manav) wrote: > Anton, >=20 > I understand that once the attacker can insert LSAs in the flooding = domain then there are several things that can be done. However, in most = cases the attacks can be easily identified and a corrective action can = be easily taken. In this particular case, the attack is a little more = insidious and its not straight forward catching the erring LSA. >=20 > Since its something that's missing in rfc 2328 we will keep having = newer implementations that will carry this bug. A short one page RFC = that updates 2328 imo would do no harm. Do you see any issue in = publishing such an RFC? There is NO bug in RFC 2328. The RFC clearly states that a Router-LSA = will be advertised with the same Router-ID for both the LSID and the = Advertising router. I don't think it is productive to write "short" RFCs = for every attack and believe the CERT Alert is a better and swifter = mechanism for disseminating information on attacks.=20 Note that my implementation was not susceptible to this attack as the = vulnerability was identified in a packet mutation suite many years back. I spoke to Gabi offline about authoring an informational RFC that = discusses classes of OSPF attacks and possible mechanisms to thwart = them.=20 Thanks, Acee >=20 > I have written a short post on what the issue in 2328 is and how it = can be exploited to launch an attack. > = http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerabi= lity-exposed-by-black-hat/ >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Anton Smirnov [mailto:asmirnov@cisco.com]=20 >> Sent: Thursday, September 12, 2013 4:46 PM >> To: Bhatia, Manav (Manav) >> Cc: Gabi Nakibly; Acee Lindem; ospf@ietf.org >> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF -=20 >> Owning the Routing Table Attack) >>=20 >> If attacker has joined flooding domain and can inject an=20 >> LSA into LSDB then it can screw up routing in the domain.=20 >> Methods such as pretending being an ABR/ASBR and advertise=20 >> destinations with good metric are almost impossible to combat=20 >> once authentication barrier is penetrated. >> This particular vulnerability allows attacker to bring=20 >> network down in style but if this vulnerability is not=20 >> present in the particular network then attacker will simply=20 >> resort to other numerous possibilities to affect routing via=20 >> LSA injection. If attacker can inject LSA into LSDB then your=20 >> network is at his mercy. Give or take one particular method=20 >> is a detail. >> So IMO we don't need a draft on this particular=20 >> vulnerability. It might be of some limited interest to=20 >> document all known methods to exploit LSA injection which=20 >> would include this vulnerability but what value would this=20 >> RFC bring? Such methods are regularly published in academic=20 >> literature since 90-th. >>=20 >> IMO we need good (reliable, secure, manageable etc)=20 >> methods of authenticating adjacencies. KARP group is working=20 >> on that. We *might* benefit from a work on mechanism to=20 >> prevent any router to originate reachable LSA on behalf of=20 >> any other router (kind of LSA signing). But work on what will=20 >> go wrong when intended security barriers are broken IMO is not = needed. >>=20 >> Anton >>=20 >>=20 >>=20 >> On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote: >>> Hi Gabi, >>>=20 >>> [clipped] >>>=20 >>>> Nonetheless, I am sure that there are more OSPF vendors out there=20= >>>> that are still vulnerable to the attack and do not check for this.=20= >>>> Moreover, since this check is not part of the standard, in most=20 >>>> likelihood future OSPF implementations will also be vulnerable. >>>>=20 >>> [clipped] >>>=20 >>>> I am willing to write a draft describing this mitigation=20 >> measure. I=20 >>>> would appreciate the list's thoughts on this. >>> I think it's a good idea to write a draft that describes=20 >> the attack and what implementations MUST do to avoid it. >>>=20 >>> Cheers, Manav >>>=20 >>=20 >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From manav.bhatia@alcatel-lucent.com Thu Sep 12 08:05:42 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E45511E820D for ; Thu, 12 Sep 2013 08:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSqmMfAKoX+i for ; Thu, 12 Sep 2013 08:05:33 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id DEB3011E821E for ; Thu, 12 Sep 2013 08:05:31 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r8CF5TdH008319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Sep 2013 10:05:30 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r8CF5R1i007729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 11:05:29 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 12 Sep 2013 11:05:27 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.83]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Thu, 12 Sep 2013 23:05:25 +0800 From: "Bhatia, Manav (Manav)" To: Acee Lindem Thread-Topic: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) Thread-Index: AQHOr8it0FQ/Zi+/Tk+kM9fPB35RJJnCMjjA Date: Thu, 12 Sep 2013 15:05:24 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E4B4A42@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5231A28C.5030102@cisco.com> <20211F91F544D247976D84C5D778A4C32E4B4924@SG70YWXCHMBA05.zap.alcatel-lucent.com> <9F1F84B6-9A14-4C6E-84C3-2D2A26754C7E@lindem.com> In-Reply-To: <9F1F84B6-9A14-4C6E-84C3-2D2A26754C7E@lindem.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:05:45 -0000 Hi Acee, =20 > There is NO bug in RFC 2328. The RFC clearly states that a=20 While I did use the "b" word, I did not mean a "bug" -- have always referre= d to it as an ommission. > Router-LSA will be advertised with the same Router-ID for=20 > both the LSID and the Advertising router. I don't think it is=20 This is at the sending side. What about the RX side? I guess that's where t= he omission was. > productive to write "short" RFCs for every attack and believe=20 > the CERT Alert is a better and swifter mechanism for=20 > disseminating information on attacks.=20 > Note that my implementation was not susceptible to this=20 > attack as the vulnerability was identified in a packet=20 > mutation suite many years back. >=20 > I spoke to Gabi offline about authoring an informational RFC=20 > that discusses classes of OSPF attacks and possible=20 > mechanisms to thwart them.=20 I am fine with that as well. I just want the different kids of attacks to g= et documented somewhere. Cheers, Manav >=20 > Thanks, > Acee >=20 > >=20 > > I have written a short post on what the issue in 2328 is=20 > and how it can be exploited to launch an attack. > >=20 > http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulne > > rability-exposed-by-black-hat/ > >=20 > > Cheers, Manav > >=20 > >> -----Original Message----- > >> From: Anton Smirnov [mailto:asmirnov@cisco.com] > >> Sent: Thursday, September 12, 2013 4:46 PM > >> To: Bhatia, Manav (Manav) > >> Cc: Gabi Nakibly; Acee Lindem; ospf@ietf.org > >> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF -=20 > Owning the=20 > >> Routing Table Attack) > >>=20 > >> If attacker has joined flooding domain and can inject=20 > an LSA into=20 > >> LSDB then it can screw up routing in the domain. > >> Methods such as pretending being an ABR/ASBR and advertise=20 > >> destinations with good metric are almost impossible to combat once=20 > >> authentication barrier is penetrated. > >> This particular vulnerability allows attacker to bring network=20 > >> down in style but if this vulnerability is not present in the=20 > >> particular network then attacker will simply resort to=20 > other numerous=20 > >> possibilities to affect routing via LSA injection. If attacker can=20 > >> inject LSA into LSDB then your network is at his mercy.=20 > Give or take=20 > >> one particular method is a detail. > >> So IMO we don't need a draft on this particular=20 > vulnerability. It=20 > >> might be of some limited interest to document all known methods to=20 > >> exploit LSA injection which would include this=20 > vulnerability but what=20 > >> value would this RFC bring? Such methods are regularly=20 > published in=20 > >> academic literature since 90-th. > >>=20 > >> IMO we need good (reliable, secure, manageable etc) methods of=20 > >> authenticating adjacencies. KARP group is working on that.=20 > We *might*=20 > >> benefit from a work on mechanism to prevent any router to=20 > originate=20 > >> reachable LSA on behalf of any other router (kind of LSA signing).=20 > >> But work on what will go wrong when intended security barriers are=20 > >> broken IMO is not needed. > >>=20 > >> Anton > >>=20 > >>=20 > >>=20 > >> On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote: > >>> Hi Gabi, > >>>=20 > >>> [clipped] > >>>=20 > >>>> Nonetheless, I am sure that there are more OSPF vendors=20 > out there=20 > >>>> that are still vulnerable to the attack and do not check=20 > for this. > >>>> Moreover, since this check is not part of the standard, in most=20 > >>>> likelihood future OSPF implementations will also be vulnerable. > >>>>=20 > >>> [clipped] > >>>=20 > >>>> I am willing to write a draft describing this mitigation > >> measure. I > >>>> would appreciate the list's thoughts on this. > >>> I think it's a good idea to write a draft that describes > >> the attack and what implementations MUST do to avoid it. > >>>=20 > >>> Cheers, Manav > >>>=20 > >>=20 > >>=20 > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf >=20 > = From uma.chunduri@ericsson.com Thu Sep 12 10:46:52 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590B421E8151 for ; Thu, 12 Sep 2013 10:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0VlHF--PFtz for ; Thu, 12 Sep 2013 10:46:47 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id EF39B21E8056 for ; Thu, 12 Sep 2013 10:46:25 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-ba-5231fdef12d2 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C1.78.09414.FEDF1325; Thu, 12 Sep 2013 19:46:23 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Thu, 12 Sep 2013 13:46:19 -0400 From: Uma Chunduri To: Acee Lindem , "Bhatia, Manav (Manav)" Thread-Topic: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) Thread-Index: AQHOr8jmYtD8kEBdl021iddA6tiarJnCW7aw Date: Thu, 12 Sep 2013 17:46:18 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863174B866E@eusaamb105.ericsson.se> References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5231A28C.5030102@cisco.com> <20211F91F544D247976D84C5D778A4C32E4B4924@SG70YWXCHMBA05.zap.alcatel-lucent.com> <9F1F84B6-9A14-4C6E-84C3-2D2A26754C7E@lindem.com> In-Reply-To: <9F1F84B6-9A14-4C6E-84C3-2D2A26754C7E@lindem.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.53.73.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPlO77v4ZBBt+2qllMuzWdzWLOvXus Fi337rE7MHu0PtvL6rFkyU8mjw+LLrAGMEdx2aSk5mSWpRbp2yVwZSzsX8FWsEy7YsLhLUwN jL3KXYycHBICJhK3Oo+wQthiEhfurWfrYuTiEBI4yiix59o2FghnOaPEvk3PmECq2AT0JD5O /ckOYosIxEm0zprHAmIzCyhLPO5azQZiCwtESyzoOMrYxcgBVBMjMfs5M0S5kUTP6hNgrSwC qhLXth8Ci/MK+EpMfzgdatdhZokVG++D7eIUsJPY0L8NzGYEuu77qTVMELvEJW49mc8EcbWA xJI955khbFGJl4//QX2jIHHgxxyo23QkFuz+xAZha0ssW/gaarGgxMmZT1gmMIrNQjJ2FpKW WUhaZiFpWcDIsoqRo7Q4tSw33chgEyMwdo5JsOnuYNzz0vIQozQHi5I47yq9M4FCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGKdPPpJzepquUOjnKwv+yS5xiIxfvo6DoYTTQtZzZ6rWHnGF 4D0l21ZrVd5Z+XybVsoRJfa9B6VneS7TseBjjT1zYNaNJHn5FIlp83+/XX8upuJUypvex4tf VB+J7Xhh13xHhe3Agd4d5gGFOvePfHrjYDPz4r+AXfEzJ3zbdHJBu9BW2Z6CI6eUWIozEg21 mIuKEwGYVYFXawIAAA== Cc: "ospf@ietf.org" Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 17:46:52 -0000 Manav, The premise of the attack is still somebody know the AUTH keys of the route= r. If private keys of the router can be possibly subverted/leaked/stolen, the= n we all agree lot of things in lot of protocols can break (not only in OSPF or this is not specific to OSPF issue= ).=20 One can definitely try to introduce protocol mechanisms to thwart some of t= hese attacks to a certain extent, but the point is the problem is not still addressable this way. The question is how far it's real (I know KARP WG is contending with this) = and what are=20 the other mechanism one can adopt to solve the issue at the root instead of= introducing=20 more complicated protocol machinery. I also feel this should be analyzed more from KARP protocol threat document= s... --=20 Uma C.=20 -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Ace= e Lindem Sent: Thursday, September 12, 2013 7:59 AM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing= Table Attack) Manav -=20 On Sep 12, 2013, at 10:40 AM, Bhatia, Manav (Manav) wrote: > Anton, >=20 > I understand that once the attacker can insert LSAs in the flooding domai= n then there are several things that can be done. However, in most cases th= e attacks can be easily identified and a corrective action can be easily ta= ken. In this particular case, the attack is a little more insidious and its= not straight forward catching the erring LSA. >=20 > Since its something that's missing in rfc 2328 we will keep having newer = implementations that will carry this bug. A short one page RFC that updates= 2328 imo would do no harm. Do you see any issue in publishing such an RFC? There is NO bug in RFC 2328. The RFC clearly states that a Router-LSA will = be advertised with the same Router-ID for both the LSID and the Advertising= router. I don't think it is productive to write "short" RFCs for every att= ack and believe the CERT Alert is a better and swifter mechanism for dissem= inating information on attacks.=20 Note that my implementation was not susceptible to this attack as the vulne= rability was identified in a packet mutation suite many years back. I spoke to Gabi offline about authoring an informational RFC that discusses= classes of OSPF attacks and possible mechanisms to thwart them.=20 Thanks, Acee >=20 > I have written a short post on what the issue in 2328 is and how it can b= e exploited to launch an attack. > http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulne > rability-exposed-by-black-hat/ >=20 > Cheers, Manav >=20 >> -----Original Message----- >> From: Anton Smirnov [mailto:asmirnov@cisco.com] >> Sent: Thursday, September 12, 2013 4:46 PM >> To: Bhatia, Manav (Manav) >> Cc: Gabi Nakibly; Acee Lindem; ospf@ietf.org >> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the=20 >> Routing Table Attack) >>=20 >> If attacker has joined flooding domain and can inject an LSA into=20 >> LSDB then it can screw up routing in the domain. >> Methods such as pretending being an ABR/ASBR and advertise=20 >> destinations with good metric are almost impossible to combat once=20 >> authentication barrier is penetrated. >> This particular vulnerability allows attacker to bring network=20 >> down in style but if this vulnerability is not present in the=20 >> particular network then attacker will simply resort to other numerous=20 >> possibilities to affect routing via LSA injection. If attacker can=20 >> inject LSA into LSDB then your network is at his mercy. Give or take=20 >> one particular method is a detail. >> So IMO we don't need a draft on this particular vulnerability. It=20 >> might be of some limited interest to document all known methods to=20 >> exploit LSA injection which would include this vulnerability but what=20 >> value would this RFC bring? Such methods are regularly published in=20 >> academic literature since 90-th. >>=20 >> IMO we need good (reliable, secure, manageable etc) methods of=20 >> authenticating adjacencies. KARP group is working on that. We *might*=20 >> benefit from a work on mechanism to prevent any router to originate=20 >> reachable LSA on behalf of any other router (kind of LSA signing).=20 >> But work on what will go wrong when intended security barriers are=20 >> broken IMO is not needed. >>=20 >> Anton >>=20 >>=20 >>=20 >> On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote: >>> Hi Gabi, >>>=20 >>> [clipped] >>>=20 >>>> Nonetheless, I am sure that there are more OSPF vendors out there=20 >>>> that are still vulnerable to the attack and do not check for this. >>>> Moreover, since this check is not part of the standard, in most=20 >>>> likelihood future OSPF implementations will also be vulnerable. >>>>=20 >>> [clipped] >>>=20 >>>> I am willing to write a draft describing this mitigation >> measure. I >>>> would appreciate the list's thoughts on this. >>> I think it's a good idea to write a draft that describes >> the attack and what implementations MUST do to avoid it. >>>=20 >>> Cheers, Manav >>>=20 >>=20 >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From glen.kent@gmail.com Thu Sep 12 14:46:13 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A749511E8115 for ; Thu, 12 Sep 2013 14:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTYwLjlsOA5u for ; Thu, 12 Sep 2013 14:46:10 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4A51C11E8101 for ; Thu, 12 Sep 2013 14:46:10 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l17so436731oag.3 for ; Thu, 12 Sep 2013 14:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jZS7zjzaA/3omHsvVBB2A2/YX/PjHsf5mr5g8QbEP5k=; b=VCE8a6G2ohdW9x19w1Fr1s+/k5d3Mou6qWBLOY1BWijrU7uJgArCUeLoVtOumY/RIe FUmtQllVjVHgmsgGPrnLG6NrIxfxlxKHC0QeAUpjuiv641wd3ImGG+EkCEZkupwqG9wp wZ8eqHW3M0Wv5+5DpSAdxR6nySD2Vj66I8iOc+NqpMlapnK8xve2oieJw9iI8lxpEfuc n9ursZCe2rdvHPKcFR3ai6SNOwOfMY3dLht8/+Mfr+ZbZo27Jt9yxLXJeJpDgznWYlqm ftxpAfYJrOgTSYGICT445HeEQbUSJSwXike7t1fIqYH6FD8MnvVx7Vtf88akp5H70yLg v97w== MIME-Version: 1.0 X-Received: by 10.60.125.202 with SMTP id ms10mr3715502oeb.69.1379022369789; Thu, 12 Sep 2013 14:46:09 -0700 (PDT) Received: by 10.182.197.42 with HTTP; Thu, 12 Sep 2013 14:46:09 -0700 (PDT) In-Reply-To: <1B502206DFA0C544B7A6046915200863174B866E@eusaamb105.ericsson.se> References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5231A28C.5030102@cisco.com> <20211F91F544D247976D84C5D778A4C32E4B4924@SG70YWXCHMBA05.zap.alcatel-lucent.com> <9F1F84B6-9A14-4C6E-84C3-2D2A26754C7E@lindem.com> <1B502206DFA0C544B7A6046915200863174B866E@eusaamb105.ericsson.se> Date: Fri, 13 Sep 2013 03:16:09 +0530 Message-ID: From: Glen Kent To: Uma Chunduri Content-Type: multipart/alternative; boundary=047d7b3a956e7d1ca304e636aa57 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 21:46:13 -0000 --047d7b3a956e7d1ca304e636aa57 Content-Type: text/plain; charset=ISO-8859-1 No, this is not the premise. Yes, somebody could do this if he has access to the keys. In this case the attack was done in the absence of any authentication being used. Glen On Thu, Sep 12, 2013 at 11:16 PM, Uma Chunduri wrote: > Manav, > > The premise of the attack is still somebody know the AUTH keys of the > router. > If private keys of the router can be possibly subverted/leaked/stolen, > then we all agree lot of things in lot of > protocols can break (not only in OSPF or this is not specific to OSPF > issue). > > One can definitely try to introduce protocol mechanisms to thwart some of > these attacks to a certain extent, > but the point is the problem is not still addressable this way. > > The question is how far it's real (I know KARP WG is contending with this) > and what are > the other mechanism one can adopt to solve the issue at the root instead > of introducing > more complicated protocol machinery. > > I also feel this should be analyzed more from KARP protocol threat > documents... > -- > Uma C. > > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Acee Lindem > Sent: Thursday, September 12, 2013 7:59 AM > To: Bhatia, Manav (Manav) > Cc: ospf@ietf.org > Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the > Routing Table Attack) > > Manav - > > > On Sep 12, 2013, at 10:40 AM, Bhatia, Manav (Manav) wrote: > > > Anton, > > > > I understand that once the attacker can insert LSAs in the flooding > domain then there are several things that can be done. However, in most > cases the attacks can be easily identified and a corrective action can be > easily taken. In this particular case, the attack is a little more > insidious and its not straight forward catching the erring LSA. > > > > Since its something that's missing in rfc 2328 we will keep having newer > implementations that will carry this bug. A short one page RFC that updates > 2328 imo would do no harm. Do you see any issue in publishing such an RFC? > > There is NO bug in RFC 2328. The RFC clearly states that a Router-LSA will > be advertised with the same Router-ID for both the LSID and the Advertising > router. I don't think it is productive to write "short" RFCs for every > attack and believe the CERT Alert is a better and swifter mechanism for > disseminating information on attacks. > Note that my implementation was not susceptible to this attack as the > vulnerability was identified in a packet mutation suite many years back. > > I spoke to Gabi offline about authoring an informational RFC that > discusses classes of OSPF attacks and possible mechanisms to thwart them. > > Thanks, > Acee > > > > > I have written a short post on what the issue in 2328 is and how it can > be exploited to launch an attack. > > http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulne > > rability-exposed-by-black-hat/ > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Anton Smirnov [mailto:asmirnov@cisco.com] > >> Sent: Thursday, September 12, 2013 4:46 PM > >> To: Bhatia, Manav (Manav) > >> Cc: Gabi Nakibly; Acee Lindem; ospf@ietf.org > >> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the > >> Routing Table Attack) > >> > >> If attacker has joined flooding domain and can inject an LSA into > >> LSDB then it can screw up routing in the domain. > >> Methods such as pretending being an ABR/ASBR and advertise > >> destinations with good metric are almost impossible to combat once > >> authentication barrier is penetrated. > >> This particular vulnerability allows attacker to bring network > >> down in style but if this vulnerability is not present in the > >> particular network then attacker will simply resort to other numerous > >> possibilities to affect routing via LSA injection. If attacker can > >> inject LSA into LSDB then your network is at his mercy. Give or take > >> one particular method is a detail. > >> So IMO we don't need a draft on this particular vulnerability. It > >> might be of some limited interest to document all known methods to > >> exploit LSA injection which would include this vulnerability but what > >> value would this RFC bring? Such methods are regularly published in > >> academic literature since 90-th. > >> > >> IMO we need good (reliable, secure, manageable etc) methods of > >> authenticating adjacencies. KARP group is working on that. We *might* > >> benefit from a work on mechanism to prevent any router to originate > >> reachable LSA on behalf of any other router (kind of LSA signing). > >> But work on what will go wrong when intended security barriers are > >> broken IMO is not needed. > >> > >> Anton > >> > >> > >> > >> On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote: > >>> Hi Gabi, > >>> > >>> [clipped] > >>> > >>>> Nonetheless, I am sure that there are more OSPF vendors out there > >>>> that are still vulnerable to the attack and do not check for this. > >>>> Moreover, since this check is not part of the standard, in most > >>>> likelihood future OSPF implementations will also be vulnerable. > >>>> > >>> [clipped] > >>> > >>>> I am willing to write a draft describing this mitigation > >> measure. I > >>>> would appreciate the list's thoughts on this. > >>> I think it's a good idea to write a draft that describes > >> the attack and what implementations MUST do to avoid it. > >>> > >>> Cheers, Manav > >>> > >> > >> > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --047d7b3a956e7d1ca304e636aa57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
No, this is not the premise. Yes, somebody could do t= his if he has access to the keys. In this case the attack was done in the a= bsence of any authentication being used.

Glen<= /div>



On Thu, Sep 12, 2013 at 11:16 PM, Uma Chunduri &l= t;uma.chundu= ri@ericsson.com> wrote:
Manav,

The premise of the attack is still somebody know the AUTH keys of the route= r.
If private keys of the router can be possibly subverted/leaked/stolen, =A0t= hen we all agree lot of things in lot of
protocols can break (not only in OSPF or this is not specific to OSPF issue= ).

One can definitely try to introduce protocol mechanisms to thwart some of t= hese attacks to a certain extent,
but the point is the problem is not still addressable this way.

The question is how far it's real (I know KARP WG is contending with th= is) and what are
the other mechanism one can adopt to solve the issue at the root instead of= introducing
more complicated protocol machinery.

I also feel this should be analyzed more from KARP protocol threat document= s...
--
Uma C.


-----Original Message-----
From: ospf-bounces@ietf.org [m= ailto:ospf-bounces@ietf.org] O= n Behalf Of Acee Lindem
Sent: Thursday, September 12, 2013 7:59 AM
To: Bhatia, Manav (Manav)
Cc: ospf@ie= tf.org
Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing= Table Attack)

Manav -


On Sep 12, 2013, at 10:40 AM, Bhatia, Manav (Manav) wrote:

> Anton,
>
> I understand that once the attacker can insert LSAs in the flooding do= main then there are several things that can be done. However, in most cases= the attacks can be easily identified and a corrective action can be easily= taken. In this particular case, the attack is a little more insidious and = its not straight forward catching the erring LSA.
>
> Since its something that's missing in rfc 2328 we will keep having= newer implementations that will carry this bug. A short one page RFC that = updates 2328 imo would do no harm. Do you see any issue in publishing such = an RFC?

There is NO bug in RFC 2328. The RFC clearly states that a Router-LSA will = be advertised with the same Router-ID for both the LSID and the Advertising= router. I don't think it is productive to write "short" RFCs= for every attack and believe the CERT Alert is a better and swifter mechan= ism for disseminating information on attacks.
Note that my implementation was not susceptible to this attack as the vulne= rability was identified in a packet mutation suite many years back.

I spoke to Gabi offline about authoring an informational RFC that discusses= classes of OSPF attacks and possible mechanisms to thwart them.

Thanks,
Acee

>
> I have written a short post on what the issue in 2328 is and how it ca= n be exploited to launch an attack.
> http://routingfreak.wordpress.com/2013/09/09= /how-bad-is-the-ospf-vulne
> rability-exposed-by-black-hat/
>
> Cheers, Manav
>
>> -----Original Message-----
>> From: Anton Smirnov [mailto:= asmirnov@cisco.com]
>> Sent: Thursday, September 12, 2013 4:46 PM
>> To: Bhatia, Manav (Manav)
>> Cc: Gabi Nakibly; Acee Lindem; os= pf@ietf.org
>> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning th= e
>> Routing Table Attack)
>>
>> =A0 =A0If attacker has joined flooding domain and can inject an LS= A into
>> LSDB then it can screw up routing in the domain.
>> Methods such as pretending being an ABR/ASBR and advertise
>> destinations with good metric are almost impossible to combat once=
>> authentication barrier is penetrated.
>> =A0 =A0This particular vulnerability allows attacker to bring netw= ork
>> down in style but if this vulnerability is not present in the
>> particular network then attacker will simply resort to other numer= ous
>> possibilities to affect routing via LSA injection. If attacker can=
>> inject LSA into LSDB then your network is at his mercy. Give or ta= ke
>> one particular method is a detail.
>> =A0 =A0So IMO we don't need a draft on this particular vulnera= bility. It
>> might be of some limited interest to document all known methods to=
>> exploit LSA injection which would include this vulnerability but w= hat
>> value would this RFC bring? Such methods are regularly published i= n
>> academic literature since 90-th.
>>
>> =A0 =A0IMO we need good (reliable, secure, manageable etc) methods= of
>> authenticating adjacencies. KARP group is working on that. We *mig= ht*
>> benefit from a work on mechanism to prevent any router to originat= e
>> reachable LSA on behalf of any other router (kind of LSA signing).=
>> But work on what will go wrong when intended security barriers are=
>> broken IMO is not needed.
>>
>> Anton
>>
>>
>>
>> On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote:
>>> Hi Gabi,
>>>
>>> [clipped]
>>>
>>>> Nonetheless, I am sure that there are more OSPF vendors ou= t there
>>>> that are still vulnerable to the attack and do not check f= or this.
>>>> Moreover, since this check is not part of the standard, in= most
>>>> likelihood future OSPF implementations will also be vulner= able.
>>>>
>>> [clipped]
>>>
>>>> I am willing to write a draft describing this mitigation >> measure. I
>>>> would appreciate the list's thoughts on this.
>>> I think it's a good idea to write a draft that describes >> the attack and what implementations MUST do to avoid it.
>>>
>>> Cheers, Manav
>>>
>>
>>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf

--047d7b3a956e7d1ca304e636aa57-- From uma.chunduri@ericsson.com Thu Sep 12 14:52:57 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D55411E81B0 for ; Thu, 12 Sep 2013 14:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMAcKTpfwS73 for ; Thu, 12 Sep 2013 14:52:52 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3137211E80F2 for ; Thu, 12 Sep 2013 14:52:51 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-71-523237b3d2a9 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AA.25.03458.3B732325; Thu, 12 Sep 2013 23:52:51 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Thu, 12 Sep 2013 17:52:51 -0400 From: Uma Chunduri To: Glen Kent Thread-Topic: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) Thread-Index: AQHOsAGAA5zyPXY+7Ui1XVcJW/ibY5nCo/5g Date: Thu, 12 Sep 2013 21:52:50 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863174B8891@eusaamb105.ericsson.se> References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5231A28C.5030102@cisco.com> <20211F91F544D247976D84C5D778A4C32E4B4924@SG70YWXCHMBA05.zap.alcatel-lucent.com> <9F1F84B6-9A14-4C6E-84C3-2D2A26754C7E@lindem.com> <1B502206DFA0C544B7A6046915200863174B866E@eusaamb105.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.53.73.29] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A6046915200863174B8891eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPrO5mc6MggxuPlSym3ZrOZrHnxHsW izn37rFatNy7x+7A4tH6bC+rx85Zd9k9liz5yeTxYdEF1gCWKC6blNSczLLUIn27BK6Ml+sn Mxe8amGs+Hp0AUsD4+r8LkZODgkBE4mXR3cxQdhiEhfurWfrYuTiEBI4yihxe+pVJghnOaPE gQ+rWEGq2AT0JD5O/cnexcjBISKgLPHmZgpImFmgXuJM105GEFtYIFpixf2HLCC2iECMxJIL bxkhbCOJPf83gsVZBFQlvqzeyQ5i8wr4Ssw+sJQZYtc5FonPPdfAGjgFAiVm7r4HZjMCXff9 1BomiGXiEreezIe6WkBiyZ7zzBC2qMTLx/9YIWwFiQM/5rBA1OdLTHq8iA1imaDEyZlPWCYw is5CMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkaO0uLUstx0I8NNjMAI PCbB5riDccEny0OM0hwsSuK8G/TOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpg3H3PxufW rjTjaSwf3vGJPkhIjzy17N5JnxmxYcd7uCq+iyiuXjw3ZPEcoR0bl9yQNfSX+6jy7GG0UrDR vNNv0rdd4NbynnV4hofD8RfX+1rmywsLffdb4XZU7aGQmilvf01IVdDiSZ6z3+1SfazWeWTC mx+SDRsi7hQF7H3FxP6v4LfBvcOHGpRYijMSDbWYi4oTARKxIgeOAgAA Cc: "ospf@ietf.org" Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 21:52:57 -0000 --_000_1B502206DFA0C544B7A6046915200863174B8891eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >> In this case the attack was done in the absence of any authentication be= ing used. One should worry for attack, if one configures some form of existing AUTH p= rotections (we have) in the network. ..else we should not spend time on this topic! -- Uma C. ________________________________ From: Glen Kent [mailto:glen.kent@gmail.com] Sent: Thursday, September 12, 2013 2:46 PM To: Uma Chunduri Cc: Acee Lindem; Bhatia, Manav (Manav); ospf@ietf.org Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing= Table Attack) No, this is not the premise. Yes, somebody could do this if he has access t= o the keys. In this case the attack was done in the absence of any authenti= cation being used. Glen On Thu, Sep 12, 2013 at 11:16 PM, Uma Chunduri > wrote: Manav, The premise of the attack is still somebody know the AUTH keys of the route= r. If private keys of the router can be possibly subverted/leaked/stolen, the= n we all agree lot of things in lot of protocols can break (not only in OSPF or this is not specific to OSPF issue= ). One can definitely try to introduce protocol mechanisms to thwart some of t= hese attacks to a certain extent, but the point is the problem is not still addressable this way. The question is how far it's real (I know KARP WG is contending with this) = and what are the other mechanism one can adopt to solve the issue at the root instead of= introducing more complicated protocol machinery. I also feel this should be analyzed more from KARP protocol threat document= s... -- Uma C. -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-boun= ces@ietf.org] On Behalf Of Acee Lindem Sent: Thursday, September 12, 2013 7:59 AM To: Bhatia, Manav (Manav) Cc: ospf@ietf.org Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing= Table Attack) Manav - On Sep 12, 2013, at 10:40 AM, Bhatia, Manav (Manav) wrote: > Anton, > > I understand that once the attacker can insert LSAs in the flooding domai= n then there are several things that can be done. However, in most cases th= e attacks can be easily identified and a corrective action can be easily ta= ken. In this particular case, the attack is a little more insidious and its= not straight forward catching the erring LSA. > > Since its something that's missing in rfc 2328 we will keep having newer = implementations that will carry this bug. A short one page RFC that updates= 2328 imo would do no harm. Do you see any issue in publishing such an RFC? There is NO bug in RFC 2328. The RFC clearly states that a Router-LSA will = be advertised with the same Router-ID for both the LSID and the Advertising= router. I don't think it is productive to write "short" RFCs for every att= ack and believe the CERT Alert is a better and swifter mechanism for dissem= inating information on attacks. Note that my implementation was not susceptible to this attack as the vulne= rability was identified in a packet mutation suite many years back. I spoke to Gabi offline about authoring an informational RFC that discusses= classes of OSPF attacks and possible mechanisms to thwart them. Thanks, Acee > > I have written a short post on what the issue in 2328 is and how it can b= e exploited to launch an attack. > http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulne > rability-exposed-by-black-hat/ > > Cheers, Manav > >> -----Original Message----- >> From: Anton Smirnov [mailto:asmirnov@cisco.com] >> Sent: Thursday, September 12, 2013 4:46 PM >> To: Bhatia, Manav (Manav) >> Cc: Gabi Nakibly; Acee Lindem; ospf@ietf.org >> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the >> Routing Table Attack) >> >> If attacker has joined flooding domain and can inject an LSA into >> LSDB then it can screw up routing in the domain. >> Methods such as pretending being an ABR/ASBR and advertise >> destinations with good metric are almost impossible to combat once >> authentication barrier is penetrated. >> This particular vulnerability allows attacker to bring network >> down in style but if this vulnerability is not present in the >> particular network then attacker will simply resort to other numerous >> possibilities to affect routing via LSA injection. If attacker can >> inject LSA into LSDB then your network is at his mercy. Give or take >> one particular method is a detail. >> So IMO we don't need a draft on this particular vulnerability. It >> might be of some limited interest to document all known methods to >> exploit LSA injection which would include this vulnerability but what >> value would this RFC bring? Such methods are regularly published in >> academic literature since 90-th. >> >> IMO we need good (reliable, secure, manageable etc) methods of >> authenticating adjacencies. KARP group is working on that. We *might* >> benefit from a work on mechanism to prevent any router to originate >> reachable LSA on behalf of any other router (kind of LSA signing). >> But work on what will go wrong when intended security barriers are >> broken IMO is not needed. >> >> Anton >> >> >> >> On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote: >>> Hi Gabi, >>> >>> [clipped] >>> >>>> Nonetheless, I am sure that there are more OSPF vendors out there >>>> that are still vulnerable to the attack and do not check for this. >>>> Moreover, since this check is not part of the standard, in most >>>> likelihood future OSPF implementations will also be vulnerable. >>>> >>> [clipped] >>> >>>> I am willing to write a draft describing this mitigation >> measure. I >>>> would appreciate the list's thoughts on this. >>> I think it's a good idea to write a draft that describes >> the attack and what implementations MUST do to avoid it. >>> >>> Cheers, Manav >>> >> >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --_000_1B502206DFA0C544B7A6046915200863174B8891eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
>> In this case th= e attack was done in the absence of any authentication being used.
One should worry for attack, if o= ne configures some form of existing AUTH protections (we have) in the = network.
..else we should not spend &= nbsp;time on this topic!
 

--=
Uma C.

 

From: Glen Kent [mailto:glen.kent@g= mail.com]
Sent: Thursday, September 12, 2013 2:46 PM
To: Uma Chunduri
Cc: Acee Lindem; Bhatia, Manav (Manav); ospf@ietf.org
Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the = Routing Table Attack)

No, this is not the premise. Yes, somebody could do this if he has acc= ess to the keys. In this case the attack was done in the absence of any aut= hentication being used.

Glen



On Thu, Sep 12, 2013 at 11:16 PM, Uma Chunduri <= span dir=3D"ltr"> <uma.chun= duri@ericsson.com> wrote:
Manav,

The premise of the attack is still somebody know the AUTH keys of the route= r.
If private keys of the router can be possibly subverted/leaked/stolen, &nbs= p;then we all agree lot of things in lot of
protocols can break (not only in OSPF or this is not specific to OSPF issue= ).

One can definitely try to introduce protocol mechanisms to thwart some of t= hese attacks to a certain extent,
but the point is the problem is not still addressable this way.

The question is how far it's real (I know KARP WG is contending with this) = and what are
the other mechanism one can adopt to solve the issue at the root instead of= introducing
more complicated protocol machinery.

I also feel this should be analyzed more from KARP protocol threat document= s...
--
Uma C.


-----Original Message-----
From: ospf-bounces@ietf.org [m= ailto:ospf-bounces@ietf.org] O= n Behalf Of Acee Lindem
Sent: Thursday, September 12, 2013 7:59 AM
To: Bhatia, Manav (Manav)
Cc: ospf@ietf.org=
Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing= Table Attack)

Manav -


On Sep 12, 2013, at 10:40 AM, Bhatia, Manav (Manav) wrote:

> Anton,
>
> I understand that once the attacker can insert LSAs in the flooding do= main then there are several things that can be done. However, in most cases= the attacks can be easily identified and a corrective action can be easily= taken. In this particular case, the attack is a little more insidious and its not straight forward catching th= e erring LSA.
>
> Since its something that's missing in rfc 2328 we will keep having new= er implementations that will carry this bug. A short one page RFC that upda= tes 2328 imo would do no harm. Do you see any issue in publishing such an R= FC?

There is NO bug in RFC 2328. The RFC clearly states that a Router-LSA will = be advertised with the same Router-ID for both the LSID and the Advertising= router. I don't think it is productive to write "short" RFCs for= every attack and believe the CERT Alert is a better and swifter mechanism for disseminating information on attacks. Note that my implementation was not susceptible to this attack as the vulne= rability was identified in a packet mutation suite many years back.

I spoke to Gabi offline about authoring an informational RFC that discusses= classes of OSPF attacks and possible mechanisms to thwart them.

Thanks,
Acee

>
> I have written a short post on what the issue in 2328 is and how it ca= n be exploited to launch an attack.
> http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulne<= br> > rability-exposed-by-black-hat/
>
> Cheers, Manav
>
>> -----Original Message-----
>> From: Anton Smirnov [mailto:= asmirnov@cisco.com]
>> Sent: Thursday, September 12, 2013 4:46 PM
>> To: Bhatia, Manav (Manav)
>> Cc: Gabi Nakibly; Acee Lindem; os= pf@ietf.org
>> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning th= e
>> Routing Table Attack)
>>
>>    If attacker has joined flooding domain and can inject= an LSA into
>> LSDB then it can screw up routing in the domain.
>> Methods such as pretending being an ABR/ASBR and advertise
>> destinations with good metric are almost impossible to combat once=
>> authentication barrier is penetrated.
>>    This particular vulnerability allows attacker to brin= g network
>> down in style but if this vulnerability is not present in the
>> particular network then attacker will simply resort to other numer= ous
>> possibilities to affect routing via LSA injection. If attacker can=
>> inject LSA into LSDB then your network is at his mercy. Give or ta= ke
>> one particular method is a detail.
>>    So IMO we don't need a draft on this particular vulne= rability. It
>> might be of some limited interest to document all known methods to=
>> exploit LSA injection which would include this vulnerability but w= hat
>> value would this RFC bring? Such methods are regularly published i= n
>> academic literature since 90-th.
>>
>>    IMO we need good (reliable, secure, manageable etc) m= ethods of
>> authenticating adjacencies. KARP group is working on that. We *mig= ht*
>> benefit from a work on mechanism to prevent any router to originat= e
>> reachable LSA on behalf of any other router (kind of LSA signing).=
>> But work on what will go wrong when intended security barriers are=
>> broken IMO is not needed.
>>
>> Anton
>>
>>
>>
>> On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote:
>>> Hi Gabi,
>>>
>>> [clipped]
>>>
>>>> Nonetheless, I am sure that there are more OSPF vendors ou= t there
>>>> that are still vulnerable to the attack and do not check f= or this.
>>>> Moreover, since this check is not part of the standard, in= most
>>>> likelihood future OSPF implementations will also be vulner= able.
>>>>
>>> [clipped]
>>>
>>>> I am willing to write a draft describing this mitigation >> measure. I
>>>> would appreciate the list's thoughts on this.
>>> I think it's a good idea to write a draft that describes
>> the attack and what implementations MUST do to avoid it.
>>>
>>> Cheers, Manav
>>>
>>
>>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf

--_000_1B502206DFA0C544B7A6046915200863174B8891eusaamb105erics_-- From acee.lindem@ericsson.com Thu Sep 12 15:10:17 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A964111E8197 for ; Thu, 12 Sep 2013 15:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3FZyxGYu32e for ; Thu, 12 Sep 2013 15:10:12 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9D51711E80F2 for ; Thu, 12 Sep 2013 15:10:12 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-10-52323bc32ae2 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 28.16.03458.4CB32325; Fri, 13 Sep 2013 00:10:12 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Thu, 12 Sep 2013 18:10:11 -0400 From: Acee Lindem To: "Bhatia, Manav (Manav)" Thread-Topic: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) Thread-Index: AQHOr8mgairws3t0mUyN6Ip72NhCAZnC7SqA Date: Thu, 12 Sep 2013 22:10:11 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470304C7DC@eusaamb101.ericsson.se> References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5231A28C.5030102@cisco.com> <20211F91F544D247976D84C5D778A4C32E4B4924@SG70YWXCHMBA05.zap.alcatel-lucent.com> <9F1F84B6-9A14-4C6E-84C3-2D2A26754C7E@lindem.com> <20211F91F544D247976D84C5D778A4C32E4B4A42@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: <20211F91F544D247976D84C5D778A4C32E4B4A42@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <32522CF35A21814DB58B69F4031EAF4B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPrO4Ra6Mggz+HxSym3ZrOZjHn3j1W i5Z799gdmD1an+1l9Viy5CeTx4dFF1gDmKO4bFJSczLLUov07RK4Mp7/4Ch4pFlx6+EJpgbG n4pdjJwcEgImEs+vzmWDsMUkLtxbD2RzcQgJHGWU2NA1GSwhJLCcUeLKhhAQm01AR+L5o3/M ILaIgK3E8827WEBsZgEniSkX1wDZHBzCAtESky6EQJTESCy58JYRwjaS+D9zGnsXIzsHi4Cq xDVZkCivgK/Ewi3XGCG2TmOReLB2Bth0ToFYiVsd+8BsRqDTvp9awwSxSVzi1pP5TBAnC0gs 2XOeGcIWlXj5+B8rhK0sseTJfqjLdCQW7P7EBmFbS/x4fIoVwtaWWLbwNTPEEYISJ2c+YZnA KD4LyYpZSNpnIWmfhaR9FpL2BYysqxg5SotTy3LTjQw3MQJj7JgEm+MOxgWfLA8xSnOwKInz btA7EygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUeLlbPEZ1Q8WPXWuNEmOOqgv2cJ0X1/v z6q1Cb3xJ+YwVZwylX+qq+pyNtTnQk3ohSMeL5+zfDA1Pu7tPtlG4DbL4ciOV8syEyMnz79w eav8piVz5z06xfKw3mzqiSPV/44cLGrLsdylrnzx6znvc5emft13rZLvztbkrIslbx68eWn1 8M2PiqVKLMUZiYZazEXFiQD2n898fwIAAA== Cc: "ospf@ietf.org" Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 22:10:17 -0000 Hi Manav,=20 On Sep 12, 2013, at 11:05 AM, Bhatia, Manav (Manav) wrote: > Hi Acee, >=20 >> There is NO bug in RFC 2328. The RFC clearly states that a=20 >=20 > While I did use the "b" word, I did not mean a "bug" -- have always refer= red to it as an ommission. >=20 >> Router-LSA will be advertised with the same Router-ID for=20 >> both the LSID and the Advertising router. I don't think it is=20 >=20 > This is at the sending side. What about the RX side? I guess that's where= the omission was. Note that if you use a simplistic reference implementation and do the LSDB = lookups during your SPF, you will have no problems. It is only optimized im= plementations that have a problem. For example, my implementation would hav= e had the problem had I not ignored the malformed LSA while the public doma= in ZebOS would not have a problem. I won't speak for any other vendor's imp= lementation on this list. Hence, there is no omission from RFC 2328 since = it describes a simplistic SPF intra-area computation in section 16.1.=20 >=20 >> productive to write "short" RFCs for every attack and believe=20 >> the CERT Alert is a better and swifter mechanism for=20 >> disseminating information on attacks.=20 >> Note that my implementation was not susceptible to this=20 >> attack as the vulnerability was identified in a packet=20 >> mutation suite many years back. >>=20 >> I spoke to Gabi offline about authoring an informational RFC=20 >> that discusses classes of OSPF attacks and possible=20 >> mechanisms to thwart them.=20 >=20 > I am fine with that as well. I just want the different kids of attacks to= get documented somewhere. A think a single OSPF(v3) vulnerabilities document would be much more usefu= l than short RFCs documenting very specific attacks. One was started in RPS= EC but never finished due to the demise of the author's company and the RPS= EC WG itself.=20 Thanks, Acee=20 >=20 > Cheers, Manav >=20 >>=20 >> Thanks, >> Acee >>=20 >>>=20 >>> I have written a short post on what the issue in 2328 is=20 >> and how it can be exploited to launch an attack. >>>=20 >> http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulne >>> rability-exposed-by-black-hat/ >>>=20 >>> Cheers, Manav >>>=20 >>>> -----Original Message----- >>>> From: Anton Smirnov [mailto:asmirnov@cisco.com] >>>> Sent: Thursday, September 12, 2013 4:46 PM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Gabi Nakibly; Acee Lindem; ospf@ietf.org >>>> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF -=20 >> Owning the=20 >>>> Routing Table Attack) >>>>=20 >>>> If attacker has joined flooding domain and can inject=20 >> an LSA into=20 >>>> LSDB then it can screw up routing in the domain. >>>> Methods such as pretending being an ABR/ASBR and advertise=20 >>>> destinations with good metric are almost impossible to combat once=20 >>>> authentication barrier is penetrated. >>>> This particular vulnerability allows attacker to bring network=20 >>>> down in style but if this vulnerability is not present in the=20 >>>> particular network then attacker will simply resort to=20 >> other numerous=20 >>>> possibilities to affect routing via LSA injection. If attacker can=20 >>>> inject LSA into LSDB then your network is at his mercy.=20 >> Give or take=20 >>>> one particular method is a detail. >>>> So IMO we don't need a draft on this particular=20 >> vulnerability. It=20 >>>> might be of some limited interest to document all known methods to=20 >>>> exploit LSA injection which would include this=20 >> vulnerability but what=20 >>>> value would this RFC bring? Such methods are regularly=20 >> published in=20 >>>> academic literature since 90-th. >>>>=20 >>>> IMO we need good (reliable, secure, manageable etc) methods of=20 >>>> authenticating adjacencies. KARP group is working on that.=20 >> We *might*=20 >>>> benefit from a work on mechanism to prevent any router to=20 >> originate=20 >>>> reachable LSA on behalf of any other router (kind of LSA signing).=20 >>>> But work on what will go wrong when intended security barriers are=20 >>>> broken IMO is not needed. >>>>=20 >>>> Anton >>>>=20 >>>>=20 >>>>=20 >>>> On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote: >>>>> Hi Gabi, >>>>>=20 >>>>> [clipped] >>>>>=20 >>>>>> Nonetheless, I am sure that there are more OSPF vendors=20 >> out there=20 >>>>>> that are still vulnerable to the attack and do not check=20 >> for this. >>>>>> Moreover, since this check is not part of the standard, in most=20 >>>>>> likelihood future OSPF implementations will also be vulnerable. >>>>>>=20 >>>>> [clipped] >>>>>=20 >>>>>> I am willing to write a draft describing this mitigation >>>> measure. I >>>>>> would appreciate the list's thoughts on this. >>>>> I think it's a good idea to write a draft that describes >>>> the attack and what implementations MUST do to avoid it. >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>=20 >>>>=20 >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>=20 >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From prz@mail.zeta2.ch Thu Sep 12 15:51:33 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1715821E80BF for ; Thu, 12 Sep 2013 15:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, J_CHICKENPOX_26=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzxpJxyMQhee for ; Thu, 12 Sep 2013 15:51:16 -0700 (PDT) Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id D1A8321E80EB for ; Thu, 12 Sep 2013 15:51:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r8CMp46t006726 for ; Fri, 13 Sep 2013 00:51:04 +0200 X-Virus-Scanned: amavisd-new at zeta2.ch Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2MBIU-Dlsq3q for ; Fri, 13 Sep 2013 00:51:03 +0200 (CEST) Received: from prz-workstation.zeta2.ch (prz-workstation.zeta2.ch [192.168.1.51]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r8CMowKo006722 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 13 Sep 2013 00:51:00 +0200 Message-ID: <52324550.5000105@zeta2.ch> Date: Fri, 13 Sep 2013 00:50:56 +0200 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: ospf@ietf.org References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5231A28C.5030102@cisco.com> <20211F91F544D247976D84C5D778A4C32E4B4924@SG70YWXCHMBA05.zap.alcatel-lucent.com> <9F1F84B6-9A14-4C6E-84C3-2D2A26754C7E@lindem.com> <1B502206DFA0C544B7A6046915200863174B866E@eusaamb105.ericsson.se> In-Reply-To: Content-Type: multipart/mixed; boundary="------------090200070203080502030708" Subject: Re: [OSPF] Dropping malformed LSAs X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 22:51:33 -0000 This is a multi-part message in MIME format. --------------090200070203080502030708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/12/2013 11:46 PM, Glen Kent wrote: > No, this is not the premise. Yes, somebody could do this if he has > access to the keys. In this case the attack was done in the absence of > any authentication being used. > this will be unfortunately the tenor of this discussion until a threat model is being talked about first in terms of what is that is being feared [protected value] and how the attack is mounted [attacker sophistication and resources]. Only then what is being done & whether a solution makes sense will be agreed upon. And on a lighter note and to keep things in perspective: In my experience over years, the worst threats to routing protocols were 01. coding bugs/naive implementation 02. coding bugs/naive implementation .. 31. coding bugs/naive implementation 32. misunderstanding of the spec 33. misunderstanding of the spec .. 66. misunderstanding of the spec 67. misconfiguration: (wonder what happens if I just inject this default route into this statement I don't understand ??? ;-) 68. misconfiguration: well, I need another patch and this one looks like it can be borrowed. 69. misconfiguration: well, let's test our spanning tree, more patches in a rack are better, right ;-) 70. deteriorating links (how about 50-60 flaps/min ?) 71. memory chip failures .. ???. malicious, intended link-state packet attacks [there were cases people breaking via telnets & stuff & (cough, cough ...) MIB writes of cause)] but I fail to remember anyone injecting LSA, replaying adjancencies or any such stuff since you simply have to be on a link that carries OSPF adj normally (unless you fwd' OSPF protocol in your network in a promiscuous fashion or naively peer on any GRE tunnel in sight) and those are hard to find on the outside. Albeit an interesting paper by Boneh shows a somewhat interesting remote adjacency attack. That shows however how sophisticated the attacker must be and he'll be debugging his code for long time until he has any success with such a threat. On the other hand, CC'suming the LSPs/LSA (well, more in ISIS unless you don't age in OSPF) when you have a router sitting in there for years was a [very good thing to do] (TM) and I saw my share of flipped bits. A memory chip never thought itself a threat possibly but it was a realistic one. so keep the blackhat-threats along the 1-71 (byzantine robustness) before worrying about people stealing keys (80% of security breaches are from the inside) and then about injection into OSPF carrying links (unless it's on the edge but then I would start to worry about 1-69. again when a no-name edge vendor configured by an optimistic admin tries to talk OSPF to you). my semi-rusty 2c ;-) --- tony --------------090200070203080502030708 Content-Type: text/x-vcard; charset=utf-8; name="prz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="prz.vcf" begin:vcard fn:A. Przygienda n:Przygienda;A. org:Zeta2 GmbH adr:;;Via Tersaggio 20;Comano;;6949;Switzerland email;internet:prz@zeta2.ch title:Dr. tel;work:+41919402767 tel;fax:+41919402768 tel;cell:+41792985900 x-mozilla-html:TRUE url:http://www.zeta2.ch version:2.1 end:vcard --------------090200070203080502030708-- From erblichs@earthlink.net Thu Sep 12 16:33:54 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2CC21E81F8 for ; Thu, 12 Sep 2013 16:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0E6he1c6VdK for ; Thu, 12 Sep 2013 16:33:49 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id B59E821E81EA for ; Thu, 12 Sep 2013 16:33:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UfMGdGtklWJagKp7LznazupF0IkIkL9Y5tLfAstZNjNNL6eob72tbad/dZEjy5fO; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [50.168.24.201] (helo=[10.0.1.5]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1VKGOP-0006mw-B4; Thu, 12 Sep 2013 19:33:45 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Mitchell Erblich In-Reply-To: <5231A28C.5030102@cisco.com> Date: Thu, 12 Sep 2013 16:33:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5231A28C.5030102@cisco.com> To: Anton Smirnov X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7953123ca55f525450d11efdaa4a613e82350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 50.168.24.201 Cc: "ospf@ietf.org" Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 23:33:54 -0000 Anton, I agree partially with the below qualifications: A valid set of LSAs that constitute a flooding attack, = where the flooding attack is based on a reverse route summarization, = should be able to be identified and mitigated, An excess of valid and invalid LSAs could be run against = an acceptable quantity of LSAs, and any quantity above X from a single = non-trusted source, could cause the equiv of a tail or a RED drop of = some percentage of LSAs per period of time,=20 =09 Some form of authentication challenge against LSAs (like = a ICMP echo request) or first recv'ing packets from the path, could be = used to validate the LSA before using the actual LSA (if the LSA is = suspect) could be done=85 Thus, as in most de facto implementations, a layering of = secure/authentication methods tend to be more effective then just at a = single layer. So, why wouldn't a best practices type document given a = set of well known attacks with SHOULDs be minimally productive? Mitchell Erblich =09 On Sep 12, 2013, at 4:16 AM, Anton Smirnov wrote: > If attacker has joined flooding domain and can inject an LSA into = LSDB then it can screw up routing in the domain. Methods such as = pretending being an ABR/ASBR and advertise destinations with good metric = are almost impossible to combat once authentication barrier is = penetrated. > This particular vulnerability allows attacker to bring network down = in style but if this vulnerability is not present in the particular = network then attacker will simply resort to other numerous possibilities = to affect routing via LSA injection. If attacker can inject LSA into = LSDB then your network is at his mercy. Give or take one particular = method is a detail. > So IMO we don't need a draft on this particular vulnerability. It = might be of some limited interest to document all known methods to = exploit LSA injection which would include this vulnerability but what = value would this RFC bring? Such methods are regularly published in = academic literature since 90-th. >=20 > IMO we need good (reliable, secure, manageable etc) methods of = authenticating adjacencies. KARP group is working on that. We *might* = benefit from a work on mechanism to prevent any router to originate = reachable LSA on behalf of any other router (kind of LSA signing). But = work on what will go wrong when intended security barriers are broken = IMO is not needed. >=20 > Anton >=20 >=20 >=20 > On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote: >> Hi Gabi, >>=20 >> [clipped] >>=20 >>> Nonetheless, I am sure that there are more OSPF vendors out >>> there that are still vulnerable to the attack and do not >>> check for this. Moreover, since this check is not part of the >>> standard, in most likelihood future OSPF implementations will >>> also be vulnerable. >>>=20 >> [clipped] >>=20 >>> I am willing to write a draft describing this mitigation >>> measure. I would appreciate the list's thoughts on this. >> I think it's a good idea to write a draft that describes the attack = and what implementations MUST do to avoid it. >>=20 >> Cheers, Manav >>=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Mon Sep 16 05:24:48 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6013E11E81EB for ; Mon, 16 Sep 2013 05:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCGVRwhwMvlC for ; Mon, 16 Sep 2013 05:24:42 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 89F9411E8213 for ; Mon, 16 Sep 2013 05:24:42 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-b2-5236f8885568 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 69.01.03458.988F6325; Mon, 16 Sep 2013 14:24:41 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Mon, 16 Sep 2013 08:24:40 -0400 From: Acee Lindem To: OSPF List Thread-Topic: Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" Thread-Index: AQHOste3EMxPsGBN8EOd8TMhWHcyKw== Date: Mon, 16 Sep 2013 12:24:39 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> References: <20130910215422.31670.58526.idtracker@ietfa.amsl.com> In-Reply-To: <20130910215422.31670.58526.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <8431139994BA4046888F78017A5239E8@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXSPt27nD7MggxVXhCxa7t1jd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv77jgWL+CpedLUzNTAe5O5i5OSQEDCReLRiKiOELSZx4d56 NhBbSOAoo8TXKVVdjFxA9nJGiZmf5oMVsQnoSDx/9I8ZxBYRkJVYumQ/K4gtLOAo0bl9J1Tc TWL+hz1Qtp5E+/V2FhCbRUBVov1ON3sXIwcHr4CvxNK1QRC7HCVeX3oFVsIp4CRxefENdhCb Eeie76fWMIHYzALiEreezGeCuFNAYsme88wQtqjEy8f/WCFsZYklT/azQNTrSCzY/YkNwraW uPz7AzuErS2xbOFrsF5eAUGJkzOfsExgFJuFZMUsJO2zkLTPQtI+C0n7AkbWVYwcpcWpZbnp RoabGIFRckyCzXEH44JPlocYpTlYlMR5N+idCRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA OO8H87fVFdY+SkuCjs/6uDHhsPvOqZv0n1wPURCKX7nkrqF/4xf/pKY62Qfr/iatTvno8muK yEEzXud20/fXS1afPMkSsGOilcLMSWGca5Ln808++ORLr72nuMjKYDHZT4v/b7O8+Fth5azM tYcmsbAnb5HjlI9webbfXS2ta+qKTnaV33vmaiixFGckGmoxFxUnAgCM/I9RYAIAAA== Subject: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 12:24:48 -0000 This version includes changes in support of backward compatibility. Speakin= g as both a WG chair and author, this document is essential to OSPFv3 proto= col extension. Please indicate your support or objections by September 30th= , 2013.=20 Thanks, Acee=20 On Sep 10, 2013, at 5:54 PM, wrote: >=20 > A new version of I-D, draft-acee-ospfv3-lsa-extend-02.txt > has been successfully submitted by Acee Lindem and posted to the > IETF repository. >=20 > Filename: draft-acee-ospfv3-lsa-extend > Revision: 02 > Title: OSPFv3 LSA Extendibility > Creation date: 2013-09-10 > Group: Individual Submission > Number of pages: 29 > URL: http://www.ietf.org/internet-drafts/draft-acee-ospfv3-ls= a-extend-02.txt > Status: http://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-ex= tend > Htmlized: http://tools.ietf.org/html/draft-acee-ospfv3-lsa-extend-= 02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospfv3-lsa= -extend-02 >=20 > Abstract: > OSPFv3 requires functional extension beyond what can readily be done > with the fixed-format Link State Advertisement (LSA) as described in > RFC 5340. Without LSA extension, attributes associated with OSPFv3 > links and advertised IPv6 prefixes must be advertised in separate > LSAs and correlated to the fixed-format LSA. This document extends > the LSA format by allowing the optional inclusion of Type-Length- > Value (TLV) tuples in the LSAs. Backward compatibility mechanisms > are also described. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From acee.lindem@ericsson.com Mon Sep 16 05:30:54 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEE711E8242 for ; Mon, 16 Sep 2013 05:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCQuM9MFJQQb for ; Mon, 16 Sep 2013 05:30:46 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C48C711E823C for ; Mon, 16 Sep 2013 05:30:45 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-3f-5236f9f3fa13 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 0C.D3.09414.4F9F6325; Mon, 16 Sep 2013 14:30:44 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Mon, 16 Sep 2013 08:30:43 -0400 From: Acee Lindem To: OSPF List Thread-Topic: Poll for WG Adoption of draft-baker-ipv6-ospf-dst-src-routing-03.txt Thread-Index: AQHOstiPFvKkLdrSeEmnp51nfAa89g== Date: Mon, 16 Sep 2013 12:30:42 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4703052AD7@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <921F18E90F202D4FB9DCC54366F6B594@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyuXRPiO6Xn2ZBBo9uiVq03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOlfrzAXnGSqOPDvNGMD4xSmLkZODgkBE4nDHdOYIWwxiQv3 1rN1MXJxCAkcZZRo/LODEcJZziixb8YlRpAqNgEdieeP/oF1iAjISixdsp8VxBYW8JX4tmYT I0Q8ROLqmaVQtp7Em4bL7CA2i4CqxIEFu9lAbF6g+ueHjoH1MgJt/n5qDdhFzALiEreezIe6 TkBiyZ7zUNeJSrx8/I8VwlaWWPJkPwtEvY7Egt2f2CBsa4mnc7ug4toSyxa+ZobYJShxcuYT lgmMIrOQrJiFpH0WkvZZSNpnIWlfwMi6ipGjtDi1LDfdyGATIzD0j0mw6e5g3PPS8hCjNAeL kjjvKr0zgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYpapDVdd+ut7tJR0ZVG7qEeVy9N7D rOnr/jjF/WnlDMup76uZx77OL0FinZLg7ba3/4xjhA66hfnHJX7ovyQ9IZszK5iB3dzs+7fU 7wua3hpLarHF73n6tWD2+29fH76Plzt4T8OV4dTFSR/augt0s++ZVK+Nr4nQEL5vPjlvhmb+ p84XkTOUWIozEg21mIuKEwGWG7s2SwIAAA== Subject: [OSPF] Poll for WG Adoption of draft-baker-ipv6-ospf-dst-src-routing-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 12:30:54 -0000 This document includes the encodings necessary for source/destination routi= ng. The source/destination routing is required by the Homenet WG in support= of flexible multi-homed IPv6 deployment. It uses the flexible OSPFv3 encod= ings. Please indicate your support or objections by September 30th, 2013.=20 Thanks, Acee = From russw@riw.us Mon Sep 16 05:32:44 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE9B11E811F for ; Mon, 16 Sep 2013 05:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuVFPz7fKH-H for ; Mon, 16 Sep 2013 05:32:39 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 069B211E8242 for ; Mon, 16 Sep 2013 05:32:39 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=RussPC) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1VLXyn-0007kG-Sr; Mon, 16 Sep 2013 05:32:38 -0700 From: "Russ White" To: "'Acee Lindem'" , "'OSPF List'" References: <20130910215422.31670.58526.idtracker@ietfa.amsl.com> <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> Date: Mon, 16 Sep 2013 08:32:43 -0400 Message-ID: <017a01ceb2d8$d7db0be0$879123a0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQD2oXgMXGTVGR0KJDDXNio2Ek/iPwL2sb2rm2C5BSA= Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 12:32:44 -0000 > This version includes changes in support of backward compatibility. Speaking > as both a WG chair and author, this document is essential to OSPFv3 protocol > extension. Please indicate your support or objections by September 30th, > 2013. Have read and support. I think this is an important capability for v3 --too long coming as it is, in fact. :-) Russ From russw@riw.us Mon Sep 16 05:33:22 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6541B11E8242 for ; Mon, 16 Sep 2013 05:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4e3KWSaUnwe for ; Mon, 16 Sep 2013 05:33:16 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id E80A511E824F for ; Mon, 16 Sep 2013 05:33:10 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=RussPC) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1VLXzK-0007n6-KO; Mon, 16 Sep 2013 05:33:10 -0700 From: "Russ White" To: "'Acee Lindem'" , "'OSPF List'" References: <94A203EA12AECE4BA92D42DBFFE0AE4703052AD7@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4703052AD7@eusaamb101.ericsson.se> Date: Mon, 16 Sep 2013 08:33:16 -0400 Message-ID: <017c01ceb2d8$eb5db4b0$c2191e10$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJmTjoU1AHSUrFUxYSpA3tLxbJMgZiZFUUw Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [OSPF] Poll for WG Adoption of draft-baker-ipv6-ospf-dst-src-routing-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 12:33:22 -0000 > This document includes the encodings necessary for source/destination > routing. The source/destination routing is required by the Homenet WG in > support of flexible multi-homed IPv6 deployment. It uses the flexible OSPFv3 > encodings. Please indicate your support or objections by September 30th, > 2013. Read and support. :-) Russ From ppsenak@cisco.com Mon Sep 16 06:13:11 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC53611E8247 for ; Mon, 16 Sep 2013 06:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aztRGwDB4Tk7 for ; Mon, 16 Sep 2013 06:13:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2029611E8121 for ; Mon, 16 Sep 2013 06:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2073; q=dns/txt; s=iport; t=1379337187; x=1380546787; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jLKBE/EYWwNBFG7vKCSMDgCHjszzDC+H3v7o2YGj8as=; b=WVT6hGWCGoGHbzMkU293O4B0htiUXxXtMOjk2NCL0psOeF7oeaVADLWf uxhEt0bLX3/mEDOv8Z0TrFriHhucHiA104Y/EYZVgsKYVKGahh/ZX7ld1 Vu6GXq06WekaMz63vlrV3rQU6wICPD2YWd1nqs/A+adeeDVhY1QoqnHu7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAIcCN1KQ/khM/2dsb2JhbABbgwc4TMB9gRsWdIIlAQEBBAEBATU2CgEQCxgJFg8JAwIBAgEVMAYNAQUCAQEFh3oHBblXj3MHhB4Dl3uBL4UBi0SDJjo X-IronPort-AV: E=Sophos;i="4.90,915,1371081600"; d="scan'208";a="159664351" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 16 Sep 2013 13:13:02 +0000 Received: from [10.148.128.69] ([10.148.128.69]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8GDD0dJ003065; Mon, 16 Sep 2013 13:13:01 GMT Message-ID: <523703DC.9090105@cisco.com> Date: Mon, 16 Sep 2013 15:13:00 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Acee Lindem References: <20130910215422.31670.58526.idtracker@ietfa.amsl.com> <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: OSPF List Subject: Re: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 13:13:12 -0000 Hi Acee, you have my strong support on this one. thanks, Peter On 9/16/13 14:24 , Acee Lindem wrote: > This version includes changes in support of backward compatibility. Speaking as both a WG chair and author, this document is essential to OSPFv3 protocol extension. Please indicate your support or objections by September 30th, 2013. > Thanks, > Acee > > On Sep 10, 2013, at 5:54 PM, > wrote: > >> >> A new version of I-D, draft-acee-ospfv3-lsa-extend-02.txt >> has been successfully submitted by Acee Lindem and posted to the >> IETF repository. >> >> Filename: draft-acee-ospfv3-lsa-extend >> Revision: 02 >> Title: OSPFv3 LSA Extendibility >> Creation date: 2013-09-10 >> Group: Individual Submission >> Number of pages: 29 >> URL: http://www.ietf.org/internet-drafts/draft-acee-ospfv3-lsa-extend-02.txt >> Status: http://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-extend >> Htmlized: http://tools.ietf.org/html/draft-acee-ospfv3-lsa-extend-02 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-acee-ospfv3-lsa-extend-02 >> >> Abstract: >> OSPFv3 requires functional extension beyond what can readily be done >> with the fixed-format Link State Advertisement (LSA) as described in >> RFC 5340. Without LSA extension, attributes associated with OSPFv3 >> links and advertised IPv6 prefixes must be advertised in separate >> LSAs and correlated to the fixed-format LSA. This document extends >> the LSA format by allowing the optional inclusion of Type-Length- >> Value (TLV) tuples in the LSAs. Backward compatibility mechanisms >> are also described. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From huaimo.chen@huawei.com Mon Sep 16 10:05:08 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2CA11E82C3 for ; Mon, 16 Sep 2013 10:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCF2C4ySfayN for ; Mon, 16 Sep 2013 10:05:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 729BF11E82B7 for ; Mon, 16 Sep 2013 10:05:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXX18210; Mon, 16 Sep 2013 17:05:01 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 16 Sep 2013 18:03:11 +0100 Received: from SJCEML401-HUB.china.huawei.com (10.212.94.42) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 16 Sep 2013 18:03:34 +0100 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.42]) by sjceml401-hub.china.huawei.com ([::1]) with mapi id 14.03.0146.000; Mon, 16 Sep 2013 10:03:29 -0700 From: Huaimo Chen To: Acee Lindem , OSPF List Thread-Topic: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" Thread-Index: AQHOste3EMxPsGBN8EOd8TMhWHcyK5nIltWw Date: Mon, 16 Sep 2013 17:03:28 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D445BA120E@sjceml501-mbs.china.huawei.com> References: <20130910215422.31670.58526.idtracker@ietfa.amsl.com> <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 17:05:08 -0000 Support! BR, Huaimo -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Ace= e Lindem Sent: Monday, September 16, 2013 8:25 AM To: OSPF List Subject: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" This version includes changes in support of backward compatibility. Speakin= g as both a WG chair and author, this document is essential to OSPFv3 proto= col extension. Please indicate your support or objections by September 30th= , 2013.=20 Thanks, Acee=20 On Sep 10, 2013, at 5:54 PM, wrote: >=20 > A new version of I-D, draft-acee-ospfv3-lsa-extend-02.txt > has been successfully submitted by Acee Lindem and posted to the IETF=20 > repository. >=20 > Filename: draft-acee-ospfv3-lsa-extend > Revision: 02 > Title: OSPFv3 LSA Extendibility > Creation date: 2013-09-10 > Group: Individual Submission > Number of pages: 29 > URL: http://www.ietf.org/internet-drafts/draft-acee-ospfv3-ls= a-extend-02.txt > Status: http://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-ex= tend > Htmlized: http://tools.ietf.org/html/draft-acee-ospfv3-lsa-extend-= 02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospfv3-lsa= -extend-02 >=20 > Abstract: > OSPFv3 requires functional extension beyond what can readily be done > with the fixed-format Link State Advertisement (LSA) as described in > RFC 5340. Without LSA extension, attributes associated with OSPFv3 > links and advertised IPv6 prefixes must be advertised in separate > LSAs and correlated to the fixed-format LSA. This document extends > the LSA format by allowing the optional inclusion of Type-Length- > Value (TLV) tuples in the LSAs. Backward compatibility mechanisms > are also described. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From zzhang@juniper.net Mon Sep 16 12:10:47 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069CC11E82F9 for ; Mon, 16 Sep 2013 12:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2oLOjUSE8sp for ; Mon, 16 Sep 2013 12:10:41 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id E785B11E8142 for ; Mon, 16 Sep 2013 12:10:40 -0700 (PDT) Received: from mail55-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE025.bigfish.com (10.3.207.147) with Microsoft SMTP Server id 14.1.225.22; Mon, 16 Sep 2013 19:10:40 +0000 Received: from mail55-am1 (localhost [127.0.0.1]) by mail55-am1-R.bigfish.com (Postfix) with ESMTP id E8200E00EA; Mon, 16 Sep 2013 19:10:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371I936eI542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail55-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=zzhang@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(24454002)(199002)(164054003)(189002)(51704005)(377454003)(377424004)(74706001)(63696002)(4396001)(54316002)(81342001)(46102001)(49866001)(47736001)(69226001)(81686001)(66066001)(77096001)(80022001)(54356001)(47976001)(65816001)(50986001)(56776001)(76796001)(81542001)(83072001)(19580395003)(83322001)(51856001)(19580405001)(74316001)(15202345003)(59766001)(76482001)(76576001)(74366001)(77982001)(56816003)(74876001)(79102001)(81816001)(76786001)(31966008)(74662001)(15975445006)(33646001)(53806001)(80976001)(47446002)(74502001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB079; H:BY2PR05MB079.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail55-am1 (localhost.localdomain [127.0.0.1]) by mail55-am1 (MessageSwitch) id 1379358638291397_18712; Mon, 16 Sep 2013 19:10:38 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.235]) by mail55-am1.bigfish.com (Postfix) with ESMTP id 39BDB1E009F; Mon, 16 Sep 2013 19:10:38 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 16 Sep 2013 19:10:38 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Mon, 16 Sep 2013 19:10:37 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 16 Sep 2013 19:10:35 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.110]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.110]) with mapi id 15.00.0745.000; Mon, 16 Sep 2013 19:10:35 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Acee Lindem , OSPF List Thread-Topic: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" Thread-Index: AQHOsw+8anrTrIRC5Em1W5uKqRNs9ZnIuqlA Date: Mon, 16 Sep 2013 19:10:35 +0000 Message-ID: <51a7c83149a04f6b87752a79340922f0@BY2PR05MB079.namprd05.prod.outlook.com> References: <20130910215422.31670.58526.idtracker@ietfa.amsl.com> <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0971922F40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 19:10:47 -0000 Support. Jeffrey > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com] > Sent: Monday, September 16, 2013 8:25 AM > To: OSPF List > Subject: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" >=20 > This version includes changes in support of backward compatibility. > Speaking as both a WG chair and author, this document is essential to > OSPFv3 protocol extension. Please indicate your support or objections > by September 30th, 2013. > Thanks, > Acee >=20 > On Sep 10, 2013, at 5:54 PM, > wrote: >=20 > > > > A new version of I-D, draft-acee-ospfv3-lsa-extend-02.txt > > has been successfully submitted by Acee Lindem and posted to the > > IETF repository. > > > > Filename: draft-acee-ospfv3-lsa-extend > > Revision: 02 > > Title: OSPFv3 LSA Extendibility > > Creation date: 2013-09-10 > > Group: Individual Submission > > Number of pages: 29 > > URL: http://www.ietf.org/internet-drafts/draft-acee- > ospfv3-lsa-extend-02.txt > > Status: http://datatracker.ietf.org/doc/draft-acee-ospfv3- > lsa-extend > > Htmlized: http://tools.ietf.org/html/draft-acee-ospfv3-lsa- > extend-02 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-acee-ospfv3- > lsa-extend-02 > > > > Abstract: > > OSPFv3 requires functional extension beyond what can readily be > done > > with the fixed-format Link State Advertisement (LSA) as described > in > > RFC 5340. Without LSA extension, attributes associated with OSPFv3 > > links and advertised IPv6 prefixes must be advertised in separate > > LSAs and correlated to the fixed-format LSA. This document extends > > the LSA format by allowing the optional inclusion of Type-Length- > > Value (TLV) tuples in the LSAs. Backward compatibility mechanisms > > are also described. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > >=20 From glen.kent@gmail.com Tue Sep 17 02:48:12 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FB711E83DB for ; Tue, 17 Sep 2013 02:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYuJTy2AJ6NM for ; Tue, 17 Sep 2013 02:48:11 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5C52E11E83C7 for ; Tue, 17 Sep 2013 02:48:11 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id va2so5058204obc.15 for ; Tue, 17 Sep 2013 02:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WDh2g07eL7YmvnqKtBHRhb94Ax1D2AyNiCXCA01ZXwo=; b=VVXB5vVi2B38JhJOCkSZJDnpuqi7V5R0r7YBtJiJwvHgTBeNwNreJfMpI3bg3uUYJU X/8w15vbW9WPZiK1vO4G5iawVUbCDaKmIS1evGMP5gg0rm+L+SeYshM368MAn9quBaQN BBxU0FM8tehmII8Vbu9HNBAyasTtIxMCY+lelL1EnKPr4SMdiEYuwqG8Z6RpVAUBNfCp bJn7/VFWcdFCQdXhpV0o1rbqWa5lTTsIzYBzgLXARekNjgrAiNt+YxmKOwlEIExF36h4 PY3kBxu+1//QaTK/ERe8tVw2pn6gcpqrHEPq6SYIBI0L6HsZK5An9sHmEcoIFL3N/AIV 6Diw== MIME-Version: 1.0 X-Received: by 10.182.49.166 with SMTP id v6mr29149483obn.13.1379411290919; Tue, 17 Sep 2013 02:48:10 -0700 (PDT) Received: by 10.182.197.42 with HTTP; Tue, 17 Sep 2013 02:48:10 -0700 (PDT) In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> References: <20130910215422.31670.58526.idtracker@ietfa.amsl.com> <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> Date: Tue, 17 Sep 2013 15:18:10 +0530 Message-ID: From: Glen Kent To: Acee Lindem Content-Type: multipart/alternative; boundary=047d7b5d2ea4fe9a6104e69137d2 Cc: OSPF List Subject: Re: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 09:48:12 -0000 --047d7b5d2ea4fe9a6104e69137d2 Content-Type: text/plain; charset=ISO-8859-1 Support. This draft blurs yet another line of difference between ISIS and OSPF, where folks from the former camp claimed that their LSPs were TLV encoded and thus easily extensible, unlike OSPF which was hard encoded. Glen On Mon, Sep 16, 2013 at 5:54 PM, Acee Lindem wrote: > This version includes changes in support of backward compatibility. > Speaking as both a WG chair and author, this document is essential to > OSPFv3 protocol extension. Please indicate your support or objections by > September 30th, 2013. > Thanks, > Acee > > On Sep 10, 2013, at 5:54 PM, > wrote: > > > > > A new version of I-D, draft-acee-ospfv3-lsa-extend-02.txt > > has been successfully submitted by Acee Lindem and posted to the > > IETF repository. > > > > Filename: draft-acee-ospfv3-lsa-extend > > Revision: 02 > > Title: OSPFv3 LSA Extendibility > > Creation date: 2013-09-10 > > Group: Individual Submission > > Number of pages: 29 > > URL: > http://www.ietf.org/internet-drafts/draft-acee-ospfv3-lsa-extend-02.txt > > Status: > http://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-extend > > Htmlized: > http://tools.ietf.org/html/draft-acee-ospfv3-lsa-extend-02 > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-acee-ospfv3-lsa-extend-02 > > > > Abstract: > > OSPFv3 requires functional extension beyond what can readily be done > > with the fixed-format Link State Advertisement (LSA) as described in > > RFC 5340. Without LSA extension, attributes associated with OSPFv3 > > links and advertised IPv6 prefixes must be advertised in separate > > LSAs and correlated to the fixed-format LSA. This document extends > > the LSA format by allowing the optional inclusion of Type-Length- > > Value (TLV) tuples in the LSAs. Backward compatibility mechanisms > > are also described. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --047d7b5d2ea4fe9a6104e69137d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support.

This draft blurs yet another l= ine of difference between ISIS and OSPF, where folks from the former camp c= laimed that their LSPs were TLV encoded and thus easily extensible, unlike = OSPF which was hard encoded.

Glen


On Mon, Sep 16, 2013 at 5:54 PM, Acee Lindem <acee.lindem@ericsson.com> wrote:
This version includes changes in support of = backward compatibility. Speaking as both a WG chair and author, this docume= nt is essential to OSPFv3 protocol extension. Please indicate your support = or objections by September 30th, 2013.
Thanks,
Acee

On Sep 10, 2013, at 5:54 PM, <internet-drafts@ietf.org>
=A0<internet-drafts@ietf.org= > wrote:

>
> A new version of I-D, draft-acee-ospfv3-lsa-extend-02.txt
> has been successfully submitted by Acee Lindem and posted to the
> IETF repository.
>
> Filename: =A0 =A0 =A0draft-acee-ospfv3-lsa-extend
> Revision: =A0 =A0 =A002
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 OSPFv3 LSA Extendibility
> Creation date: =A0 =A0 =A0 =A0 2013-09-10
> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 29
> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.iet= f.org/internet-drafts/draft-acee-ospfv3-lsa-extend-02.txt
> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org= /doc/draft-acee-ospfv3-lsa-extend
> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draf= t-acee-ospfv3-lsa-extend-02
> Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org= /rfcdiff?url2=3Ddraft-acee-ospfv3-lsa-extend-02
>
> Abstract:
> =A0 OSPFv3 requires functional extension beyond what can readily be do= ne
> =A0 with the fixed-format Link State Advertisement (LSA) as described = in
> =A0 RFC 5340. =A0Without LSA extension, attributes associated with OSP= Fv3
> =A0 links and advertised IPv6 prefixes must be advertised in separate<= br> > =A0 LSAs and correlated to the fixed-format LSA. =A0This document exte= nds
> =A0 the LSA format by allowing the optional inclusion of Type-Length-<= br> > =A0 Value (TLV) tuples in the LSAs. =A0Backward compatibility mechanis= ms
> =A0 are also described.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf

--047d7b5d2ea4fe9a6104e69137d2-- From asmirnov@cisco.com Tue Sep 17 05:48:21 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D118C11E8417 for ; Tue, 17 Sep 2013 05:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAkz+2N1+JfG for ; Tue, 17 Sep 2013 05:48:16 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 123E711E8418 for ; Tue, 17 Sep 2013 05:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2680; q=dns/txt; s=iport; t=1379422096; x=1380631696; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QMEgzO9WUrjZU/i2eDP3+vUkLaT5n3fLi8C49PfyRLU=; b=BZ6F9G5Cg9X4zG8r75S7mAs/MO7LoZS6ydqb27yqP6KoAj2IAF9vLXMg FlxW03K+hag0rzx79/J356TobvSNtcIvAINOwMsJe0MsDCdB1bg8OVQVh 9GJHN/pdl6+WWW96H3AHf20IphtbRfNlc71faO2BcqtaF68XTQrI5T5ZW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFABhPOFKQ/khN/2dsb2JhbABbgwc4TMEcgRwWdIIlAQEBBAEBATU2AgkQCxgJJQ8CFjAGDQEFAgEBBYd6BwW6N44egUkHhB4Dl3uBL5BFgyY6gTU X-IronPort-AV: E=Sophos;i="4.90,923,1371081600"; d="scan'208";a="86724972" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 17 Sep 2013 12:48:13 +0000 Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8HCmAlt015795; Tue, 17 Sep 2013 12:48:11 GMT Message-ID: <52384F8A.70607@cisco.com> Date: Tue, 17 Sep 2013 14:48:10 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: Acee Lindem References: <20130910215422.31670.58526.idtracker@ietfa.amsl.com> <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: OSPF List Subject: Re: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:48:21 -0000 I strongly support this work. IMO we need the same work to be done with OSPFv2. Shall it be part of this document or work on its own is a separate question. Number of I-Ds submitted against OSPFv2 shows that this version of the protocol is still being actively worked on and in medium term many extensions will have to be simultaneously proposed for v2 and v3. Having Extendable LSAs in both protocol versions would greatly simplify standardization and development of such extensions. I have a few notes on current draft but I do not want to hijack this thread for technical discussion and better send another email. Thanks, Anton On 09/16/2013 02:24 PM, Acee Lindem wrote: > This version includes changes in support of backward compatibility. Speaking as both a WG chair and author, this document is essential to OSPFv3 protocol extension. Please indicate your support or objections by September 30th, 2013. > Thanks, > Acee > > On Sep 10, 2013, at 5:54 PM, > wrote: > >> A new version of I-D, draft-acee-ospfv3-lsa-extend-02.txt >> has been successfully submitted by Acee Lindem and posted to the >> IETF repository. >> >> Filename: draft-acee-ospfv3-lsa-extend >> Revision: 02 >> Title: OSPFv3 LSA Extendibility >> Creation date: 2013-09-10 >> Group: Individual Submission >> Number of pages: 29 >> URL: http://www.ietf.org/internet-drafts/draft-acee-ospfv3-lsa-extend-02.txt >> Status: http://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-extend >> Htmlized: http://tools.ietf.org/html/draft-acee-ospfv3-lsa-extend-02 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-acee-ospfv3-lsa-extend-02 >> >> Abstract: >> OSPFv3 requires functional extension beyond what can readily be done >> with the fixed-format Link State Advertisement (LSA) as described in >> RFC 5340. Without LSA extension, attributes associated with OSPFv3 >> links and advertised IPv6 prefixes must be advertised in separate >> LSAs and correlated to the fixed-format LSA. This document extends >> the LSA format by allowing the optional inclusion of Type-Length- >> Value (TLV) tuples in the LSAs. Backward compatibility mechanisms >> are also described. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From asmirnov@cisco.com Tue Sep 17 06:23:45 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7945011E8221 for ; Tue, 17 Sep 2013 06:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaA1Sq6jZi6B for ; Tue, 17 Sep 2013 06:23:39 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8CF11E8458 for ; Tue, 17 Sep 2013 06:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7789; q=dns/txt; s=iport; t=1379424217; x=1380633817; h=message-id:date:from:mime-version:to:subject; bh=AeERaB97Zbx7TZoTtNPa4ud5My6LaxJISG1fhJROZP8=; b=iD9NGjpLwmPcWmmuQaqjpcZlMasBM+sYouMPq526puhf3/ExjrUB/Pd7 6D5EkKrsk4RsVUlSjyFzPFEbsaP/L6b1V4ynKwO8k4CLaXz/Qzus802mY o97EAcE5kRMHKZCeUutv47nbua9PF4CdfnrNHYXyU1ThfOaUIeLDHWPyD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsGAA5XOFKQ/khR/2dsb2JhbABbgweKEbksFm0HgiUBAQEDeQY3FhgDAgECAUsNCAEBh3kGmWOgXpQMA5Qfg1yRdIMmOg X-IronPort-AV: E=Sophos;i="4.90,923,1371081600"; d="scan'208,217";a="18075860" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 17 Sep 2013 13:23:35 +0000 Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8HDNXZf026666 for ; Tue, 17 Sep 2013 13:23:33 GMT Message-ID: <523857D5.7050903@cisco.com> Date: Tue, 17 Sep 2013 15:23:33 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: "ospf@ietf.org" Content-Type: multipart/alternative; boundary="------------060207010202000503080409" Subject: [OSPF] Notes on draft-acee-ospfv3-lsa-extend-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 13:23:45 -0000 This is a multi-part message in MIME format. --------------060207010202000503080409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, a few notes on current revision of ELSA draft (starting from editorialgoing to more important). Cosmetic notes: > 6. OSPFv3 E-Inter-Area-Prefix-LSA > ... > All LSA Header fields are the same as defined for the Network-LSA. Should be IAP LSA. > Lindem, et al. Expires March 14, 2014 [Page 20] > > Internet-Draft OSPFv3 LSA Extendibility September 2013 > > > families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV > is only applicable to the E-Link-LSA. Inclusion in other Extended > LSAs MUST be ignored. Only a single instance of the IPv6 Link-Local > Address family SHOULD be included in the E-Link-LSA. Instances > preceding the first MUST be ignored. It is probably meant to be "instances following the first ..." Page 21: > Address family SHOULD be included in the E-Link-LSA. Instances > preceding the first MUST be ignored. For IPv6 address families as > defined in [OSPFV3-AF]. Incomplete sentence. > For simplicity and to avoid the scaling impact of maintaining both > TLV and non-TLV based versions of the same LSA within a routing > domain, the basic backward compatibility mode will not allow mixing > of LSA formats. Different formats could still be supported with > multiple OSPFv3 instances and separate OSPFv3 routing domains. "Basic compatibility mode" is confusing name for a mode when instance enabled with new functionality will not even talk to instance not enabled for (or not supporting) it. Notes to functionality: Tag field in E-ASE-LSAs is made optional. Subject of propagating tags together with Intra- and Inter- area routes was raised more than once. It is very likely that sooner or later tag sub-TLVs will be proposed for Intra- and Inter- Area E-LSA. In this case implementations will have to deal with optional tag field in E-ASE LSA and tag sub-TLV in Intra-/Inter- Prefix TLV. This is inconvenient. It is better to avoid optional field in E-ASE-LSA and define tag sub-TLV for External-Prefix TLV from the beginning. > In order to retain compatibility and semantics with the current > OSPFv3 specification, each LSA MUST contain a single Inter-Area > Prefix TLV. This will facilitate migration and avoid changes to > functions such as incremental SPF computation. I appreciate ease of migration. OTOH, for better or worse but E-Intra-Area-Prefix LSA can propagate multiple prefixes in single LSA. So well-developed implementation will have to be able to work with an LSA advertising multiple prefixes. It is a pity to restrict once and forever Inter- and Ex- Prefix TLVs if Intra- does not have such limitation. To give implementations possibility of future optimizations (advertising multiple prefixes in single LSA) and still keep advantage of faster standardization and deployment I propose: - Allow Inter- and Ex- TLVs to be present more than once in respective LSAs - Stipulate that routers running in any Migration mode MUST advertise TLV only once per LSA. Thanks, Anton --------------060207010202000503080409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit    Hi,
   a few notes on current revision of ELSA draft  (starting from editorial going to more important).

Cosmetic notes:

6.  OSPFv3 E-Inter-Area-Prefix-LSA
...
   All LSA Header fields are the same as defined for the Network-LSA.

Should be IAP LSA.


Lindem, et al.           Expires March 14, 2014                [Page 20]

Internet-Draft          OSPFv3 LSA Extendibility          September 2013


   families as defined in [OSPFV3-AF].  The IPv6 Link-Local Address TLV
   is only applicable to the E-Link-LSA.  Inclusion in other Extended
   LSAs MUST be ignored.  Only a single instance of the IPv6 Link-Local
   Address family SHOULD be included in the E-Link-LSA.  Instances
   preceding the first MUST be ignored.

It is probably meant to be "instances following the first ..."



Page 21:
   Address family SHOULD be included in the E-Link-LSA.  Instances
   preceding the first MUST be ignored.  For IPv6 address families as
   defined in [OSPFV3-AF].
Incomplete sentence.


   For simplicity and to avoid the scaling impact of maintaining both
   TLV and non-TLV based versions of the same LSA within a routing
   domain, the basic backward compatibility mode will not allow mixing
   of LSA formats. Different formats could still be supported with
   multiple OSPFv3 instances and separate OSPFv3 routing domains.
"Basic compatibility mode" is confusing name for a mode when instance enabled with new functionality will not even talk to instance not enabled for (or not supporting) it.



Notes to functionality:

Tag field in E-ASE-LSAs is made optional.
Subject of propagating tags together with Intra- and Inter- area routes was raised more than once. It is very likely that sooner or later tag sub-TLVs will be proposed for Intra- and Inter- Area E-LSA. In this case implementations will have to deal with optional tag field in E-ASE LSA and tag sub-TLV in Intra-/Inter- Prefix TLV. This is inconvenient. It is better to avoid optional field in E-ASE-LSA and define tag sub-TLV for External-Prefix TLV from the beginning.



   In order to retain compatibility and semantics with the current
   OSPFv3 specification, each LSA MUST contain a single Inter-Area
   Prefix TLV.  This will facilitate migration and avoid changes to
   functions such as incremental SPF computation.
I appreciate ease of migration. OTOH, for better or worse but E-Intra-Area-Prefix LSA can propagate multiple prefixes in single LSA. So well-developed implementation will have to be able to work with an LSA advertising multiple prefixes. It is a pity to restrict once and forever Inter- and Ex- Prefix TLVs if Intra- does not have such limitation.
   To give implementations possibility of future optimizations (advertising multiple prefixes in single LSA) and still keep advantage of faster standardization and deployment I propose:
- Allow Inter- and Ex- TLVs to be present more than once in respective LSAs
- Stipulate that routers running in any Migration mode MUST advertise TLV only once per LSA.

Thanks,

Anton



--------------060207010202000503080409-- From asmirnov@cisco.com Tue Sep 17 06:39:54 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8EA11E81EB for ; Tue, 17 Sep 2013 06:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVLulM6FY9uS for ; Tue, 17 Sep 2013 06:39:48 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id D691911E8221 for ; Tue, 17 Sep 2013 06:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2208; q=dns/txt; s=iport; t=1379425187; x=1380634787; h=message-id:date:from:mime-version:to:subject; bh=z+QbG2hZOqkcFTi4wS0uSRJe+G8IB/Sk56CgvA1I7Vc=; b=VvtGVhXQr9K94pgHIngexuDGh2c1iJ5LpRVTZIRhWScQja98gflucg/7 weDVbdqe1ruSzEPm/0E2JJJe5hVid2iTwRPy3PlpdyVJfRzit8WjH3KUQ DTxOMJvi7KI6zgOib5mNIRJQoABpbx5coBPedXd3BnwuTbT9D+ajL+f5A o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroFAMpaOFKQ/khN/2dsb2JhbABbgweKEbkxFm0HgyQgARwWGAMCAQIBSw0IAQGHf5lmoF+UDAOXe5F0gyY6 X-IronPort-AV: E=Sophos;i="4.90,923,1371081600"; d="scan'208,217";a="18076184" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 17 Sep 2013 13:39:46 +0000 Received: from asm-lnx.cisco.com (ams-asmirnov-8712.cisco.com [10.55.140.83]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8HDdi4D029881 for ; Tue, 17 Sep 2013 13:39:44 GMT Message-ID: <52385BA0.2030801@cisco.com> Date: Tue, 17 Sep 2013 15:39:44 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: "ospf@ietf.org" Content-Type: multipart/alternative; boundary="------------030407050108080605020804" Subject: [OSPF] Question to the field people X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 13:39:54 -0000 This is a multi-part message in MIME format. --------------030407050108080605020804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, it should be pretty obvious where this question is coming from but ... I would appreciate if people using OSPF in their networks answered (privately, if you want) a simple question: ISIS allows link metric to be in the range of 1-2^24 and path cost during SPF calculation 2^32. OSPF uses costs of 2^16 and 2^24 respectively. Was it ever considered as a limitation or serious factor affecting choice of IGP to usein the network? Thanks, Anton --------------030407050108080605020804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit    Hi all,
   it should be pretty obvious where this question is coming from but ...
   I would appreciate if people using OSPF in their networks answered (privately, if you want) a simple question:

ISIS allows link metric to be in the range of 1-2^24 and path cost during SPF calculation 2^32.
OSPF uses costs of 2^16 and 2^24 respectively.
Was it ever considered as a limitation or serious factor affecting choice of IGP to use in the network?

Thanks,

Anton

 --------------030407050108080605020804-- From ietf-ipr@ietf.org Tue Sep 17 15:23:36 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29F221F9ED4; Tue, 17 Sep 2013 15:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sV4cRSWzB3x; Tue, 17 Sep 2013 15:23:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EC621F9D22; Tue, 17 Sep 2013 15:23:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: akatlas@juniper.net, jdrake@juniper.net, Spencer.giacalone@thomsonreuters.com, sprevidi@cisco.com, dward@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917222336.6526.26287.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 15:23:36 -0700 Cc: ospf@ietf.org, ipr-announce@ietf.org Subject: [OSPF] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-ospf-te-metric-extensions-04 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 22:23:37 -0000 Dear Alia Atlas, John Drake, Spencer Giacalone, Stefano Previdi, David Ward: An IPR disclosure that pertains to your Internet-Draft entitled "OSPF Traf= fic Engineering (TE) Metric Extensions" (draft-ietf-ospf-te-metric-extensions) = was submitted to the IETF Secretariat on 2013-09-17 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2199/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-ospf-te-metric- extensions-04.""); The IETF Secretariat From ietf-ipr@ietf.org Tue Sep 17 15:38:22 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DD211E85F9; Tue, 17 Sep 2013 15:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.394 X-Spam-Level: X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAvdnf50jvea; Tue, 17 Sep 2013 15:38:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8913611E85EB; Tue, 17 Sep 2013 15:38:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: aretana@cisco.com,sratliff@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917223821.25317.53605.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 15:38:21 -0700 Cc: ospf@ietf.org, ipr-announce@ietf.org Subject: [OSPF] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-ospf-manet-single-hop-or-02 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 22:38:22 -0000 Dear Alvaro Retana, Stan Ratliff: An IPR disclosure that pertains to your Internet-Draft entitled "Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks" (draft-ietf-ospf-man= et- single-hop-or) was submitted to the IETF Secretariat on 2013-09-17 and has = been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2201/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-ospf-manet-single-hop-or-02= .""); The IETF Secretariat From ppsenak@cisco.com Wed Sep 18 00:56:42 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1C611E81BF for ; Wed, 18 Sep 2013 00:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADAUaHaymTK1 for ; Wed, 18 Sep 2013 00:56:37 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id DF74411E81AF for ; Wed, 18 Sep 2013 00:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3292; q=dns/txt; s=iport; t=1379490974; x=1380700574; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IBZsYolsnGy+XFlszYCW4js/j9mYLcH24h29Xkt290I=; b=JsjlTxkQiQdPXku4oTEroAjKXOEWE/Vxq5vPb4huMMC17TMrrfdATCsb RlAArnU39wSPWFqamZIVrKW/groNRUvjX33WSnMFTlEGZnMFF/5e2VF5/ eTnNIQelXD3s9qqb0FWPqT9nPsFpLEgvITZlYrWuUHDmA599gsGx0WG8Q k=; X-IronPort-AV: E=Sophos;i="4.90,929,1371081600"; d="scan'208";a="86745321" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 18 Sep 2013 07:56:11 +0000 Received: from [10.55.51.202] (ams-ppsenak-8719.cisco.com [10.55.51.202]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8I7u9OV021427; Wed, 18 Sep 2013 07:56:09 GMT Message-ID: <52395C99.3060605@cisco.com> Date: Wed, 18 Sep 2013 09:56:09 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Anton Smirnov References: <20130910215422.31670.58526.idtracker@ietfa.amsl.com> <94A203EA12AECE4BA92D42DBFFE0AE4703052A81@eusaamb101.ericsson.se> <52384F8A.70607@cisco.com> In-Reply-To: <52384F8A.70607@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: OSPF List Subject: Re: [OSPF] Poll for WG Adoption of "draft-acee-ospfv3-lsa-extend" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 07:56:42 -0000 Anton, On 9/17/13 14:48 , Anton Smirnov wrote: > I strongly support this work. > IMO we need the same work to be done with OSPFv2. Shall it be part > of this document or work on its own is a separate question. > Number of I-Ds submitted against OSPFv2 shows that this version of > the protocol is still being actively worked on and in medium term many > extensions will have to be simultaneously proposed for v2 and v3. Having > Extendable LSAs in both protocol versions would greatly simplify > standardization and development of such extensions. I have posted a similar comment on the list when I started the SR extensions for OSPFv2. The consensus at that time was to take the path of the complimentary Opaque LSAs rather then redefining existing LSAs types. This has been reflected in the draft-psenak-ospf-segment-routing-extensions. thanks, Peter > > I have a few notes on current draft but I do not want to hijack this > thread for technical discussion and better send another email. > > Thanks, > > Anton > > > > > > > > On 09/16/2013 02:24 PM, Acee Lindem wrote: >> This version includes changes in support of backward compatibility. >> Speaking as both a WG chair and author, this document is essential to >> OSPFv3 protocol extension. Please indicate your support or objections >> by September 30th, 2013. >> Thanks, >> Acee >> >> On Sep 10, 2013, at 5:54 PM, >> wrote: >> >>> A new version of I-D, draft-acee-ospfv3-lsa-extend-02.txt >>> has been successfully submitted by Acee Lindem and posted to the >>> IETF repository. >>> >>> Filename: draft-acee-ospfv3-lsa-extend >>> Revision: 02 >>> Title: OSPFv3 LSA Extendibility >>> Creation date: 2013-09-10 >>> Group: Individual Submission >>> Number of pages: 29 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-acee-ospfv3-lsa-extend-02.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-acee-ospfv3-lsa-extend >>> Htmlized: >>> http://tools.ietf.org/html/draft-acee-ospfv3-lsa-extend-02 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-acee-ospfv3-lsa-extend-02 >>> >>> Abstract: >>> OSPFv3 requires functional extension beyond what can readily be done >>> with the fixed-format Link State Advertisement (LSA) as described in >>> RFC 5340. Without LSA extension, attributes associated with OSPFv3 >>> links and advertised IPv6 prefixes must be advertised in separate >>> LSAs and correlated to the fixed-format LSA. This document extends >>> the LSA format by allowing the optional inclusion of Type-Length- >>> Value (TLV) tuples in the LSAs. Backward compatibility mechanisms >>> are also described. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > . > From chenxibj@cn.ibm.com Wed Sep 18 13:21:38 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F9311E8111 for ; Wed, 18 Sep 2013 13:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wda8Ml6cNpLb for ; Wed, 18 Sep 2013 13:21:28 -0700 (PDT) Received: from e23smtp02.au.ibm.com (e23smtp02.au.ibm.com [202.81.31.144]) by ietfa.amsl.com (Postfix) with ESMTP id 9999611E810D for ; Wed, 18 Sep 2013 13:21:27 -0700 (PDT) Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 19 Sep 2013 06:11:09 +1000 Received: from d23dlp02.au.ibm.com (202.81.31.213) by e23smtp02.au.ibm.com (202.81.31.208) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 19 Sep 2013 06:11:07 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id AC7B72BB0052 for ; Thu, 19 Sep 2013 06:11:06 +1000 (EST) Received: from d23av05.au.ibm.com (d23av05.au.ibm.com [9.190.234.119]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8IKAth510813764 for ; Thu, 19 Sep 2013 06:10:55 +1000 Received: from d23av05.au.ibm.com (localhost [127.0.0.1]) by d23av05.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r8IKB6IU031084 for ; Thu, 19 Sep 2013 06:11:06 +1000 Received: from d23ml021.cn.ibm.com (d23ml021.cn.ibm.com [9.119.32.97]) by d23av05.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r8IKB5Zx031067 for ; Thu, 19 Sep 2013 06:11:06 +1000 Auto-Submitted: auto-generated From: Xi R Chen To: ospf@ietf.org Message-ID: Date: Thu, 19 Sep 2013 04:08:40 +0800 X-MIMETrack: Serialize by Router on d23ml021/23/M/IBM(Release 8.5.3FP2HF29 | July 24, 2012) at 09/19/2013 04:08:43 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=C7BBF179DFFD2EF28f9e8a93df938690918cC7BBF179DFFD2EF2" Content-Disposition: inline X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13091820-5490-0000-0000-0000042D5C03 Subject: [OSPF] AUTO: Xi R Chen is out of the office (returning 09/20/2013) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 20:21:38 -0000 --0__=C7BBF179DFFD2EF28f9e8a93df938690918cC7BBF179DFFD2EF2 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 09/20/2013. Note: This is an automated response to your message "OSPF Digest, Vol = 91, Issue 12" sent on 09/19/2013 3:00:52. This is the only notification you will receive while this person is awa= y.= --0__=C7BBF179DFFD2EF28f9e8a93df938690918cC7BBF179DFFD2EF2 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 09= /20/2013.




Note: Thi= s is an automated response to your message  "OSPF Digest, Vol 91, Issue 12"<= /font> sent= on 09/19/2013 3:00:52.

This is t= he only notification you will receive while this person is away.= = --0__=C7BBF179DFFD2EF28f9e8a93df938690918cC7BBF179DFFD2EF2-- From RAMAKRISHNADTV@infosys.com Fri Sep 20 00:03:59 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E2721F84DB for ; Fri, 20 Sep 2013 00:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isiE8XHqXYDJ for ; Fri, 20 Sep 2013 00:03:54 -0700 (PDT) Received: from KECGATE08.infosys.com (kecgate08.infosys.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9163021F8447 for ; Fri, 20 Sep 2013 00:03:53 -0700 (PDT) X-TM-IMSS-Message-ID: <6721c729000f837f@infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 6721c729000f837f ; Fri, 20 Sep 2013 12:42:21 +0530 Received: from BLRKECHUB08.ad.infosys.com (10.66.236.138) by blrkechub03.ad.infosys.com (10.66.236.43) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 20 Sep 2013 12:33:46 +0530 Received: from BLRKECMBX22.ad.infosys.com ([fe80::f035:6246:a69c:67fc]) by BLRKECHUB08.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 12:33:45 +0530 From: RAMAKRISHNADTV To: "ospf@ietf.org" Thread-Topic: Stub areas and type 4 summary LSAs Thread-Index: AQHOtc9NvgaxpxDB2EG3xZqdC9whwA== Date: Fri, 20 Sep 2013 07:03:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.132] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OSPF] Stub areas and type 4 summary LSAs X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 07:03:59 -0000 Hi, Could you please clarify the following point in OSPFv2 (RFC 2328) w.r.t stub areas? The following is excerpted from Section 10.6 (Receiving Database Descript= ion Packets): When the router accepts a received Database Description Packet as the next in sequence the packet contents are processed as follows. For each LSA listed, the LSA's LS type is checked for validity. If the LS type is unknown (e.g., not one of the LS types 1-5 defined by this specification), or if this is an AS- external-LSA (LS type =3D 5) and the neighbor is associated with = a stub area, generate the neighbor event SeqNumberMismatch and stop processing the packet. Otherwise, the router looks up the LSA in its database to see whether it also has an instance of ... This is correctly saying that stub areas should not process external LSAs (LS type 5). But what about type 4 summary LSAs (related to ASBR)? As far as I understand, stub areas should not receive these LSAs. But this paragraph is not explicit about it. I believe this paragraph needs to be updated to indicate that received type 4 summary LSAs and type 5 external LSAs should elicit the same behavior in stub areas: generate the neighbor event SeqNumberMismatch and stop processing the packet. On the other hand, originating LSA side description in RFC correctly states as follows. >From Section 12.4.3 (Summary-LSAs): ...If so, a Type 4 summary-LSA is originated for the destination, with Link State ID equal to the AS boundary router's Router ID and metric equal to the routing table entry's cost. Note: these LSAs should not be generated if Area A has been configured as a stub area.... Regards, Ramakrishna DTV. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease notify the sender by e-mail and delete the original message. Further, you= are not to copy, disclose, or distribute this e-mail or its contents to any other= person and any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken every reasonable precaution to minimize this risk, but is not liable for = any damage you may sustain as a result of any virus in this e-mail. You should carry= out your own virus checks before opening the e-mail or attachment. Infosys reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From acee.lindem@ericsson.com Fri Sep 20 05:09:20 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D11421F898A for ; Fri, 20 Sep 2013 05:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdO7wT6aRvh0 for ; Fri, 20 Sep 2013 05:09:14 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9C42C21F89A5 for ; Fri, 20 Sep 2013 05:09:14 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-93-523c3ae9c71d Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 12.20.09414.9EA3C325; Fri, 20 Sep 2013 14:09:13 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Fri, 20 Sep 2013 08:09:13 -0400 From: Acee Lindem To: RAMAKRISHNADTV Thread-Topic: [OSPF] Stub areas and type 4 summary LSAs Thread-Index: AQHOtc9NvgaxpxDB2EG3xZqdC9whwJnOy92A Date: Fri, 20 Sep 2013 12:09:12 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470305B9B0@eusaamb101.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <002EA6C5BEF2F846A442A61A7AB0FC63@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXRPoO5LK5sgg337jSxa7t1jt5h94CaT A5PHkiU/mTwWTGpjD2CK4rJJSc3JLEst0rdL4Mq4/nwZc8FEqYplc1qYGhgninQxcnJICJhI fPyxkAXCFpO4cG89WxcjF4eQwFFGiWnfzrFAOMsZJRoXX2EGqWIT0JF4/ugfmC0ioC+x5s5p RhCbWUBZ4nHXajYQW1jATOLnihNANRxANeYSc3amQpQbSexf9wSslUVAVeJL+3mwcl4BX4nt Z/+zgthCAoES86c3g43kFAiSuH7lEFgNI9Bx30+tYYJYJS5x68l8JoijBSSW7DnPDGGLSrx8 /I8VwlaWWPJkPwtEvY7Egt2f2CBsa4n5sxdBzdGWWLbwNTPEDYISJ2c+YZnAKD4LyYpZSNpn IWmfhaR9FpL2BYysqxg5SotTy3LTjQw2MQKj6pgEm+4Oxj0vLQ8xSnOwKInzrtI7EygkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBMTCt/PZV1RWzzExW7bSrm296aun/7FgPrTqvLVO6dvry PNIVepWbKfN678Tlv2RlfkQvvbGl/HfMoaCEw1eF3Hf79xnvlbl0ekLvTbFQm6iqf1OTFAz2 5OZX9pxUyzBSrXys9ik865XVApP/E/5eCnw43W0DQ4l0v3xtyHyuysPuDlo7ugLZlFiKMxIN tZiLihMB2QlUWngCAAA= Cc: "ospf@ietf.org" Subject: Re: [OSPF] Stub areas and type 4 summary LSAs X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 12:09:20 -0000 Hi Ramakrisha, You are correct and my implementation does, in fact, generate a SeqNumberMi= smatch event in this case.=20 Thanks, Acee=20 On Sep 20, 2013, at 3:03 AM, RAMAKRISHNADTV wrote: > Hi, >=20 > Could you please clarify the following point in OSPFv2 (RFC 2328) w.r.t > stub areas? >=20 > The following is excerpted from Section 10.6 (Receiving Database Descript= ion > Packets): >=20 > When the router accepts a received Database Description Packet > as the next in sequence the packet contents are processed as > follows. For each LSA listed, the LSA's LS type is checked for > validity. If the LS type is unknown (e.g., not one of the LS > types 1-5 defined by this specification), or if this is an AS- > external-LSA (LS type =3D 5) and the neighbor is associated with a > stub area, generate the neighbor event SeqNumberMismatch and > stop processing the packet. Otherwise, the router looks up the > LSA in its database to see whether it also has an instance of > ... >=20 > This is correctly saying that stub areas should not process external > LSAs (LS type 5). But what about type 4 summary LSAs (related to ASBR)? > As far as I understand, stub areas should not receive these LSAs. > But this paragraph is not explicit about it. I believe this paragraph > needs to be updated to indicate that received type 4 summary LSAs and > type 5 external LSAs should elicit the same behavior in stub areas: > generate the neighbor event SeqNumberMismatch and stop processing the > packet. >=20 > On the other hand, originating LSA side description in RFC correctly > states as follows. >=20 > From Section 12.4.3 (Summary-LSAs): >=20 > ...If so, a Type 4 summary-LSA is originated for the > destination, with Link State ID equal to the AS boundary > router's Router ID and metric equal to the routing table > entry's cost. Note: these LSAs should not be generated > if Area A has been configured as a stub area.... >=20 > Regards, > Ramakrishna DTV. >=20 >=20 > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely=20 > for the use of the addressee(s). If you are not the intended recipient, p= lease=20 > notify the sender by e-mail and delete the original message. Further, you= are not=20 > to copy, disclose, or distribute this e-mail or its contents to any other= person and=20 > any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken=20 > every reasonable precaution to minimize this risk, but is not liable for = any damage=20 > you may sustain as a result of any virus in this e-mail. You should carry= out your=20 > own virus checks before opening the e-mail or attachment. Infosys reserve= s the=20 > right to monitor and review the content of all messages sent to or from t= his e-mail=20 > address. Messages sent to or from this e-mail address may be stored on th= e=20 > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From wwwrun@rfc-editor.org Mon Sep 23 21:00:30 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6E421F8E8E for ; Mon, 23 Sep 2013 21:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwS01HhGLhsQ for ; Mon, 23 Sep 2013 21:00:29 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id CB0C621F8C40 for ; Mon, 23 Sep 2013 21:00:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B22B6B1E00B; Mon, 23 Sep 2013 20:53:40 -0700 (PDT) To: jmoy@casc.com, stbryant@cisco.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com From: RFC Errata System Message-Id: <20130924035340.B22B6B1E00B@rfc-editor.org> Date: Mon, 23 Sep 2013 20:53:40 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC2328 (3734) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 04:00:31 -0000 The following errata report has been submitted for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3734 -------------------------------------- Type: Technical Reported by: Ramakrishna DTV Section: 8.2 Original Text ------------- The AuType specified in the packet must match the AuType specified for the associated area. Corrected Text -------------- The AuType specified in the packet must match the AuType specified for the associated interface. Notes ----- In OSPFv2, authentication is configured per interface and not per area. Appendix D clarifies this: "The authentication type is configurable on a per-interface (or equivalently, on a per-network/subnet) basis." Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : INTERNET STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From acee.lindem@ericsson.com Thu Sep 26 18:18:59 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AA621F9CB0 for ; Thu, 26 Sep 2013 18:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iScjKozRdso5 for ; Thu, 26 Sep 2013 18:18:54 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 003D521F8EEA for ; Thu, 26 Sep 2013 18:18:53 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-86-5244dcfcd0a3 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 21.DA.09414.CFCD4425; Fri, 27 Sep 2013 03:18:52 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Thu, 26 Sep 2013 21:18:52 -0400 From: Acee Lindem To: RFC Errata System Thread-Topic: [Technical Errata Reported] RFC2328 (3734) Thread-Index: AQHOuNqdMbIYjallz0uxnL2l5GiHspnZEGQA Date: Fri, 27 Sep 2013 01:18:51 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4703068C98@eusaamb101.ericsson.se> References: <20130924035340.B22B6B1E00B@rfc-editor.org> In-Reply-To: <20130924035340.B22B6B1E00B@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyuXRPiO6fOy5BBvu6dSx+9Nxgtjh8cBab xcS5MhYt9+6xW8w+cJPJomn/VzaLc0/nMDqwe/xbvY3ZY8rvjaweS5b8ZPJYMKmN3WPF5pWM Hg1tx1gD2KK4bFJSczLLUov07RK4Mt7P/stacIKvYs6rbvYGxhbuLkYODgkBE4kHpzK7GDmB TDGJC/fWs3UxcnEICRxllLi8YBkThLOcUeL87KmsIFVsAjoSzx/9YwaxRQQMJQ4uessOUsQs 0MUk0fbxCDtIQljAXKLt9CwmiCILiXP3OqAajCRutF4Gq2ERUJX4O30bmM0r4Cux9vYEsBoh oN5J9xeCLeME6n27/RhYDSPQed9PrQGbySwgLnHryXwmiLMFJJbsOc8MYYtKvHz8jxXCVpZY 8mQ/C0S9jsSC3Z/YIGxriZ3btzBC2NoSyxa+Zoa4QVDi5MwnLBMYxWchWTELSfssJO2zkLTP QtK+gJF1FSNHaXFqWW66kcEmRmC8HpNg093BuOel5SFGaQ4WJXHeL2+dg4QE0hNLUrNTUwtS i+KLSnNSiw8xMnFwSjUwNv5S+etqm2hfm9Cs9vH/VXubVW9ddSe90ZT6w9STe/bQme/rVq95 efOPxbrzNrsEHnf5zXo2l1O0WGtFxhkWuZ960U3uqRuc2lV2WH+olA0uXmL209t584f3xdEt 7hLPo8zjJFWKeNzXf5XhqJkz0efe/Ve1bwOTr1ZHJnO6qRZL5TyVebldiaU4I9FQi7moOBEA DlNlxqUCAAA= Cc: "" , "" Subject: Re: [OSPF] [Technical Errata Reported] RFC2328 (3734) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 01:18:59 -0000 I concur with this errata and would classify it as "editorial.=20 Acee=20 On Sep 23, 2013, at 11:53 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC2328, > "OSPF Version 2". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D2328&eid=3D3734 >=20 > -------------------------------------- > Type: Technical > Reported by: Ramakrishna DTV >=20 > Section: 8.2 >=20 > Original Text > ------------- > The AuType specified in the packet must match the AuType > specified for the associated area. >=20 >=20 > Corrected Text > -------------- > The AuType specified in the packet must match the AuType > specified for the associated interface. >=20 >=20 > Notes > ----- > In OSPFv2, authentication is configured per interface and not per area. > Appendix D clarifies this: "The authentication type is configurable on= a per-interface > (or equivalently, on a per-network/subnet) basis." >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC2328 (no draft string recorded) > -------------------------------------- > Title : OSPF Version 2 > Publication Date : April 1998 > Author(s) : J. Moy > Category : INTERNET STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG From abdussalambaryun@gmail.com Fri Sep 27 03:39:50 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C371D11E813A for ; Fri, 27 Sep 2013 03:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YNMijYyhEYg for ; Fri, 27 Sep 2013 03:39:49 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 11FAA21F9FCF for ; Fri, 27 Sep 2013 03:39:44 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so2436042pdj.31 for ; Fri, 27 Sep 2013 03:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7ushYIMA7HNmQUITiloWRdZRwrsLti0SvstC3ndw8Bc=; b=PsE5LlpMRt9p2ng72DfaFrao0LdPTtUHarMo++YqheWVbuU0r54wQk1EdMK64VPdSO qhSrB2EgDT7vrJIKawVD6a+tRgJLjCA968uHRJk6lSNnkZsZQ6t2fm1SboYQWKZiJpBw I1hFXdpZNPcpjdBCsX28OyqFOGmeWmahAneglq1ADxen9vtft8kjq6aOvf7SZGe6INtr 3E/9Bqw8nA9Vp6TI4ULVZ3aX6QS3SyskU6WiOsUQZ2Jjpnt0I/Q6cskVxqvjrF2DL0Yw 4r3mN6aSvdI+Apk1XCdLtFxwLjhEtV9D43WaXB6C/cApH/pKvNQEE8v6cROzGng1arO/ nJ6A== MIME-Version: 1.0 X-Received: by 10.68.197.104 with SMTP id it8mr6473700pbc.17.1380278383467; Fri, 27 Sep 2013 03:39:43 -0700 (PDT) Received: by 10.69.8.5 with HTTP; Fri, 27 Sep 2013 03:39:43 -0700 (PDT) In-Reply-To: <20130924035340.B22B6B1E00B@rfc-editor.org> References: <20130924035340.B22B6B1E00B@rfc-editor.org> Date: Fri, 27 Sep 2013 12:39:43 +0200 Message-ID: From: Abdussalam Baryun To: OSPF List Content-Type: text/plain; charset=ISO-8859-1 Cc: jmoy@casc.com Subject: Re: [OSPF] [Technical Errata Reported] RFC2328 (3734) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 10:39:50 -0000 I don't think it was an editorial error, it is technical error, AB On 9/24/13, RFC Errata System wrote: > The following errata report has been submitted for RFC2328, > "OSPF Version 2". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3734 > > -------------------------------------- > Type: Technical > Reported by: Ramakrishna DTV > > Section: 8.2 > > Original Text > ------------- > The AuType specified in the packet must match the AuType > specified for the associated area. > > > Corrected Text > -------------- > The AuType specified in the packet must match the AuType > specified for the associated interface. > > > Notes > ----- > In OSPFv2, authentication is configured per interface and not per area. > Appendix D clarifies this: "The authentication type is configurable on a > per-interface > (or equivalently, on a per-network/subnet) basis." > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC2328 (no draft string recorded) > -------------------------------------- > Title : OSPF Version 2 > Publication Date : April 1998 > Author(s) : J. Moy > Category : INTERNET STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From acee.lindem@ericsson.com Fri Sep 27 06:57:19 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDEF11E814F for ; Fri, 27 Sep 2013 06:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMuDi9JFU4HH for ; Fri, 27 Sep 2013 06:57:13 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6161121F9D12 for ; Fri, 27 Sep 2013 06:57:13 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-03-52458eb56d0b Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8D.45.03458.5BE85425; Fri, 27 Sep 2013 15:57:10 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 09:56:59 -0400 From: Acee Lindem To: Abdussalam Baryun , OSPF List Thread-Topic: [OSPF] [Technical Errata Reported] RFC2328 (3734) Thread-Index: AQHOuNqdMbIYjallz0uxnL2l5GiHspnZrRmA///BvwA= Date: Fri, 27 Sep 2013 13:56:59 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4703069A2F@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <0396652D192B6C4AB6248B5FD150B760@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZXLonQXdbn2uQwedPHBbfbrQyWfzoucFs cfjgLDaLiXNlLFru3WO3OPd0DqMDm8e/1duYPab83sjqsXPWXXaPJUt+Mnms2LySMYA1issm JTUnsyy1SN8ugSvj9aJFrAU/BSv2PC1tYPzG28XIySEhYCLRef8gO4QtJnHh3nq2LkYuDiGB o4wST+f8YARJCAksZ5R4/FEMxGYT0JF4/ugfM4gtIuArcWpeJzNIA7PAAkaJB73bwSYJC9hJ dB7pZ4Uospfoa2qAsq0k/j+6zgZiswioSrTM2MICYvMCDVpx9D9YnFMgUOLJoZtMIDYj0EXf T60Bs5kFxCVuPZnPBHGpgMSSPeeZIWxRiZeP/4HNFxXQk+ietZwVIq4s8X3OIxaIXh2JBbs/ Ac3nALKtJRZeMYUIa0ssW/iaGeIEQYmTM5+wTGAUn4Vk2ywk3bMQumch6Z6FpHsBI+sqRo7S 4tSy3HQjw02MwKg8JsHmuINxwSfLQ4zSHCxK4rxf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamCMO/qG1c3IZcEK5au11i2JxoovT1crZD+beeTcocaPV3bWVGWaLhRSD5g6IVL85vwd 5zYHbtEK9rjyY5rofROnn2sLysv9mc8dfmubmnaDI1nmqpHC7xdf9IXfxJTU1IadOar45dSX wAnXbvK8tTey0OI+tXbyrcBDkc7fclJnb961OOTpxebDSizFGYmGWsxFxYkAXzxKW5gCAAA= Cc: "jmoy@casc.com" Subject: Re: [OSPF] [Technical Errata Reported] RFC2328 (3734) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 13:57:19 -0000 Since area level authentication has been deprecated since RFC 2178, it would be impossible for this remnant from pre-RFC2178 OSPFv2 to be misinterpreted.=20 Thanks, Acee On 9/27/13 3:39 AM, "Abdussalam Baryun" wrote: >I don't think it was an editorial error, it is technical error, > >AB > >On 9/24/13, RFC Errata System wrote: >> The following errata report has been submitted for RFC2328, >> "OSPF Version 2". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D2328&eid=3D3734 >> >> -------------------------------------- >> Type: Technical >> Reported by: Ramakrishna DTV >> >> Section: 8.2 >> >> Original Text >> ------------- >> The AuType specified in the packet must match the AuType >> specified for the associated area. >> >> >> Corrected Text >> -------------- >> The AuType specified in the packet must match the AuType >> specified for the associated interface. >> >> >> Notes >> ----- >> In OSPFv2, authentication is configured per interface and not per area. >> Appendix D clarifies this: "The authentication type is configurable >>on a >> per-interface >> (or equivalently, on a per-network/subnet) basis." >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC2328 (no draft string recorded) >> -------------------------------------- >> Title : OSPF Version 2 >> Publication Date : April 1998 >> Author(s) : J. Moy >> Category : INTERNET STANDARD >> Source : Open Shortest Path First IGP >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> From acee.lindem@ericsson.com Sat Sep 28 14:20:43 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3325F11E817D for ; Sat, 28 Sep 2013 14:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE8GMoT5VzfI for ; Sat, 28 Sep 2013 14:20:37 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B3D3E11E8182 for ; Sat, 28 Sep 2013 14:20:34 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-b4-5247481e53e9 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BE.00.09414.F1847425; Sat, 28 Sep 2013 23:20:31 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Sat, 28 Sep 2013 17:20:30 -0400 From: Acee Lindem To: Acee Lindem , OSPF List Thread-Topic: [OSPF] RFC 6506Bis - Supporting Authentication Trailer for OSPFv3 Thread-Index: AQHOqAEy4u96D7SYkEyFoJvmvADslZnbntMA Date: Sat, 28 Sep 2013 21:20:29 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470306C0C3@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470303AE7F@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470306C0C3eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPuK68h3uQwcVLIhYt9+6xW5x7OofR gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4+fcja8FU9YptbWvYGhg3K3YxcnJICJhI zFjczw5hi0lcuLeeDcQWEjjKKPFtU0gXIxeQvZxRYs3124wgCTYBHYnnj/4xg9giAq4Sb5+u A2tgFlCXONm9F6iGg0NYIEBi2uxUEFNEIFCi5XYRhGkksabJGqSYRUBV4ty9TywgNq+Ar8TC 9/vAbE4BP4lFW56DXcMIdM33U2uYIIaLS9x6Mp8J4koBiSV7zjND2KISLx//YwWxRQX0JLpn LWeFiCtLLHmynwWiN1/izJmNbBC7BCVOznzCMoFRdBaSsbOQlM1CUgYR15FYsPsTG4StLbFs 4WtmGPvMgcdQvdYSq7Z2sCKrWcDIsYqRo7Q4tSw33chgEyMwzo5JsOnuYNzz0vIQozQHi5I4 75e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGDdsPzJzPudN3ZkC+b/Ewya12SlOum3+ 42jO+sTItqknNiTxGal+vjvxz8Vrsu1rWgybVKV/nrq1OlpjYSVLyuzTL4K++J5s/84uxlgS Uvh26bHlmn/uX5gva8huv53F7/Btu7qcKz/iEupe+U7eL/fy88kgZalDz48uKZl4nenQn0ub j007unWKEktxRqKhFnNRcSIAoKHJXIECAAA= Subject: Re: [OSPF] RFC 6506Bis - Supporting Authentication Trailer for OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 21:20:43 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470306C0C3eusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OSPF WG last call has ended and we will be submitting the document to t= he ADs for publication. Please unicast me if you would like to become more = involved by being the document shepherd. In routing we have both an advanta= ge and disadvantage with respect to other areas in that most of our active = WG participants have day jobs. This is good since the participants are clos= er to the implementations but bad in that it leaves less time for IETF acti= vities. I fall into this trap and find myself doing my IETF work in my copi= ous spare time. Thanks, Acee From: Ericsson > Date: Monday, September 2, 2013 10:23 AM To: OSPF List > Cc: Vishwas Manral > Subject: [OSPF] RFC 6506Bis - Supporting Authentication Trailer for OSPFv3 All, I have now received review confirmation from every one either involved in e= rrata for RFC 6506 or suggesting minor changes which were accepted. Additio= nally, Sean Turner, Security AD, reviewed the added text discussing the cho= ice of key length. At this time, I'd like to start a 2 week WG last call on= the RFC6506Bis draft. The last call will end at 12:00 AM PDT on September = 17th, 2013. Please review the document and send any comments to the list pr= ior to that time. Here is a URL for your convenience: http://www.ietf.org/id/draft-ietf-ospf-rfc6506bis-00.txt Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE470306C0C3eusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <27BE984B1CAC5C4D9443E759A6D1F7C2@ericsson.com> Content-Transfer-Encoding: quoted-printable

The OSPF WG last call has ended and we will be submitting the document= to the ADs for publication. Please unicast me if you would like to become = more involved by being the document shepherd. In routing we have both an ad= vantage and disadvantage with respect to other areas in that most of our active WG participants have day jobs. T= his is good since the participants are closer to the implementations but ba= d in that it leaves less time for IETF activities. I fall into this trap an= d find myself doing my IETF work in my copious spare time. 
Thanks,
Acee 

From: Ericsson <acee.lindem@ericsson.com>
Date: Monday, September 2, 2013 10:= 23 AM
To: OSPF List <ospf@ietf.org>
Cc: Vishwas Manral <vishwas.manral@hp.com>
Subject: [OSPF] RFC 6506Bis - Suppo= rting Authentication Trailer for OSPFv3

All,=20

I have now received review confirmation from every one either involved in e=
rrata for RFC 6506 or suggesting minor changes which were accepted. Additio=
nally, Sean Turner, Security AD, reviewed the added text discussing the cho=
ice of key length. At this time, I'd like to start a 2 week WG last call on=
 the RFC6506Bis draft. The last call will end at 12:00 AM PDT on September =
17th, 2013. Please review the document and send any comments to the list pr=
ior to that time. Here is a URL for your convenience:=20

Thanks,
Acee 
 --_000_94A203EA12AECE4BA92D42DBFFE0AE470306C0C3eusaamb101erics_-- From prz@mail.zeta2.ch Sun Sep 29 08:23:02 2013 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D143121F9FA5 for ; Sun, 29 Sep 2013 08:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQtFZx0-Kdft for ; Sun, 29 Sep 2013 08:22:57 -0700 (PDT) Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id A09DE21F9FBE for ; Sun, 29 Sep 2013 08:22:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r8TFMr8H027057 for ; Sun, 29 Sep 2013 17:22:53 +0200 X-Virus-Scanned: amavisd-new at zeta2.ch Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AHtuHKEB4Zg2 for ; Sun, 29 Sep 2013 17:22:53 +0200 (CEST) Received: from [10.71.12.110] ([63.239.94.10]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r8TFMnPv026876 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 29 Sep 2013 17:22:51 +0200 Message-ID: <524845F5.9030009@zeta2.ch> Date: Sun, 29 Sep 2013 17:23:33 +0200 From: "A. Przygienda" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "'OSPF List'" Content-Type: multipart/alternative; boundary="------------060803090508040106060404" Subject: [OSPF] as to 'threat-models' and sophisticated attacks ;-) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 15:23:02 -0000 This is a multi-part message in MIME format. --------------060803090508040106060404 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit As to the earlier discussion of 'sophisticated threats' and traffic injections. An old acquaintace with good amount of scar tissue recently pointed out to me a most instructive paper in another areathat interestingly enough documents what I wrote half in jest a while earlier. The read is 'B4: Experience with a Globally-Deployed ...' by U. Hoelzle & rest of Google gang in Aug. SigComm (for the faint of heart, it's an easy read, light on math, rich on practical experience). Section 7 documents a ('classical' in my experience) routing control melt-down as to the ones I experienced over years. Starting with second most common problem (human configuration error) leading right into most common problem (i.e. naive implementation not priotizing lsp/hellos) leading to the (in this case not catastrophical since when you own the infrastructure of all routers you can reboot them all) total meltdown (kind of, TE stayed up in frozen state). The 'conclusions' in the paper are correctwhen also some a tad belated ['We need to test things under load' ;-) ] Again, entertaining read for all practictioners of the routing game and in itself quite impressive workin terms of size/volume & novelty of approach (for the specific use case);-) --- tony --------------060803090508040106060404 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit

As to the earlier discussion of 'sophisticated threats' and traffic injections.

An old acquaintace with good amount of scar tissue recently pointed out to me 
a most instructive paper in another area that interestingly enough documents what I wrote half in jest a while earlier.

The read is 'B4: Experience with a Globally-Deployed ...' by U. Hoelzle & rest of Google gang in Aug. SigComm (for the faint of heart, it's an easy read, light on math, rich on practical experience).

Section 7 documents a ('classical' in my experience) routing control melt-down as to the ones I experienced over years.

Starting with second most common problem (human configuration error) leading right into most common problem (i.e. naive implementation not priotizing lsp/hellos) leading to the (in this case not catastrophical since when you own the infrastructure  of all routers you can reboot them all) total meltdown (kind of, TE stayed up in frozen state). 

The 'conclusions' in the paper are correct when also some a tad belated   ['We need to test things under load' ;-) ]

Again, entertaining read for all practictioners of the routing game and in itself quite impressive work in terms of size/volume & novelty of approach (for the specific use case) ;-)

--- tony


--------------060803090508040106060404--