From ppsenak@cisco.com Fri Aug 2 02:02:46 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 7CC3811E81A9 for ; Fri, 2 Aug 2013 02:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.373 X-Spam-Level: X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 NctmGjmVQ0f4 for ; Fri, 2 Aug 2013 02:02:14 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E54EC11E82E8 for ; Fri, 2 Aug 2013 01:56:16 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r728uFIc026754 for ; Fri, 2 Aug 2013 10:56:16 +0200 (CEST) Received: from [10.61.109.86] (dhcp-10-61-109-86.cisco.com [10.61.109.86]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r728uFZB028520; Fri, 2 Aug 2013 10:56:15 +0200 (CEST) Message-ID: <51FB7431.6010707@cisco.com> Date: Fri, 02 Aug 2013 10:56:17 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: OSPF List Subject: [OSPF] draft-acee-ospfv3-lsa-extend-01.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: Fri, 02 Aug 2013 09:02:46 -0000 Hi Acee, here are my comments/suggestions: 1. add an AF indicator for all prefix advertisements. This will help down the road when one instance will be used for multiple AFs. 2. Remove metric field from all top level TLVs and introduce optional Metric sub-TLV instead. It may also be wise to add MT-ID field to the Metric sub-TLV. I don't quite believe MT is dead. 3. Set the U-bit on all new extended LSAs, so that they are flooded by routers that do not understand them. 4. On the backward compatibility side, we should separate the origination of the extended LSAs from the usage of these LSAs during SPF. The local behavior for these two things should be set independently. This would give us all the flexibility we need for the migration. thanks, Peter From glen.kent@gmail.com Fri Aug 2 09:41: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 F39DF21E80FB for ; Fri, 2 Aug 2013 09:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 bSzEtO9F4PvY for ; Fri, 2 Aug 2013 09:41:02 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D124B21E80FA for ; Fri, 2 Aug 2013 09:41:01 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so1570862obc.31 for ; Fri, 02 Aug 2013 09:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gKfoItnHXFv/AJOE96rIn6INf4ys1etTSY/ZVL2zuEY=; b=mxdBANF2gVieMjNZHUubPusObdgBDX01m/PFHqAM4HZe3jyVsK2ph3KgeIo+aBsLwL YazRaGJ2qtYR1kQ/W7zNevNUQr82c2oNetXixdjG8KHLgLmLFfmmsb5o+syvF20DbZpv fGoNKKJC3ix7dFhAOXZxc+LManTWY6hISl6+sDefcPxLMq5zy1vUKCI9/hLKnQXNeWHH 83ccWjVbKyDpAuwtRBjgP9qch/SnTwMvWtL3+cLT4OwVZfWX8724kRraLiJ9JnY/Y7iE kX7lKglOrM462CmYHeIfM7F8jfBz+vueA5FDRXJaBzNhNia0xbl7t/XmfjI3yeElkVhX VwMg== MIME-Version: 1.0 X-Received: by 10.182.27.74 with SMTP id r10mr5921473obg.63.1375461661400; Fri, 02 Aug 2013 09:41:01 -0700 (PDT) Received: by 10.182.137.129 with HTTP; Fri, 2 Aug 2013 09:41:01 -0700 (PDT) Date: Fri, 2 Aug 2013 22:11:01 +0530 Message-ID: From: Glen Kent To: "ospf@ietf.org" Content-Type: multipart/alternative; boundary=089e01184b2ebae54804e2f99f7e Subject: [OSPF] 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: Fri, 02 Aug 2013 16:41:03 -0000 --089e01184b2ebae54804e2f99f7e Content-Type: text/plain; charset=ISO-8859-1 Hi, Does anybody have details on what this OSPF vulnerability is? https://www.blackhat.com/us-13/briefings.html#Nakibly Glen --089e01184b2ebae54804e2f99f7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Does anybody have details on what t= his OSPF vulnerability is?

Glen

--089e01184b2ebae54804e2f99f7e-- From uma.chunduri@ericsson.com Fri Aug 2 10:19:37 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 ECB9B21E80C2 for ; Fri, 2 Aug 2013 10:19:37 -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 ERS7Nty3-4eh for ; Fri, 2 Aug 2013 10:19:32 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2C56921F9E51 for ; Fri, 2 Aug 2013 10:19:32 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-43-51fbea1c2412 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 99.CF.31362.C1AEBF15; Fri, 2 Aug 2013 19:19:24 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Fri, 2 Aug 2013 13:19:24 -0400 From: Uma Chunduri To: Glen Kent , "ospf@ietf.org" Thread-Topic: [OSPF] OSPF - Owning the Routing Table Attack Thread-Index: AQHOj58i/36FKErcrkCmoibJVlArvpmCKN1g Date: Fri, 2 Aug 2013 17:19:23 +0000 Message-ID: <1B502206DFA0C544B7A604691520086317449883@eusaamb105.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: [155.53.73.25] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A604691520086317449883eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPoK7Mq9+BBrva5Cz2nHjPYtFy7x67 A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxcNcf9oIV0hVrt7SzNTA2SXQxcnJICJhI 9G6dzgJhi0lcuLeerYuRi0NI4CijxNdTb6CcZYwS279uYASpYhPQk/g49Sc7iC0i4CLx+fR0 MFtYwEriw/oFTF2MHEBxa4nn8/0gSowk7hx6AtbKIqAisX/9JmYQm1fAV2LVyptgrUICARJb ew6AtXIKBEqsbBYCCTMC3fP91BomEJtZQFzi1pP5TBB3Ckgs2XOeGcIWlXj5+B8rhK0gsbVt O1R9vsTjw1fYIVYJSpyc+YRlAqPILCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQ xRcwsq9i5CgtTi3LTTcy3MQIjJ1jEmyOOxgXfLI8xCjNwaIkzrtB70ygkEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBkaT/DPVDeKpAixvm7c5JOj/FNlyTT3rxmW2g6I7vFfeyoztTF1z5q77 x2abm2L3aybM0Dt4xehmk+qJMPmb3/a4VNX3HqxKvJmx6uuJRWoZy5S9uLeouW+oL1jd+kNK KLaMpeqJ4yWVEl3Ztb9nJGi9+hVQq6Xwwj/R3C6ovH7dzNbzAf+MOZRYijMSDbWYi4oTAQ9y XP1rAgAA Subject: Re: [OSPF] 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: Fri, 02 Aug 2013 17:19:38 -0000 --_000_1B502206DFA0C544B7A604691520086317449883eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Remembered comments about this in SAAG. If authentication shared secrets are compromised (insider attack) you can e= nvision all sorts of issues. If this is still considered serious consider changing keys or use a key man= agement protocol (hope there will be one defined) to do this periodically! -- Uma C. ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Gle= n Kent Sent: Friday, August 02, 2013 9:41 AM To: ospf@ietf.org Subject: [OSPF] OSPF - Owning the Routing Table Attack Hi, Does anybody have details on what this OSPF vulnerability is? https://www.blackhat.com/us-13/briefings.html#Nakibly Glen --_000_1B502206DFA0C544B7A604691520086317449883eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Remembered comments about this in= SAAG.
 
If authentication shared secrets = are compromised (insider attack) you can envision all sorts of issues.
 
If this is still considered serio= us consider changing keys or use a key management protocol (hope there will= be one defined) to do this periodically!
 

--=
Uma C.

 

From: ospf-bounces@ietf.org [mailto= :ospf-bounces@ietf.org] On Behalf Of Glen Kent
Sent: Friday, August 02, 2013 9:41 AM
To: ospf@ietf.org
Subject: [OSPF] OSPF - Owning the Routing Table Attack

Hi,

Does anybody have details on what this OSPF vulnerability is?

Glen

--_000_1B502206DFA0C544B7A604691520086317449883eusaamb105erics_-- From erblichs@earthlink.net Fri Aug 2 10:51: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 C91C211E8107 for ; Fri, 2 Aug 2013 10:51:56 -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 y4EKQXMICm4W for ; Fri, 2 Aug 2013 10:51:50 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7A511E8113 for ; Fri, 2 Aug 2013 10:51:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=E48r49HwrKOKIqiZKiTsaPioc0ziypah2crGG8EMdlX4whTb7n0al5LQ3Q/VK5Xu; h=Received:From:Content-Type:Content-Transfer-Encoding:Subject:Date:Message-Id:Cc:To:Mime-Version:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [50.168.24.201] (helo=[10.0.1.5]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1V5JVp-0008Nj-GI; Fri, 02 Aug 2013 13:51:37 -0400 From: Mitchell Erblich Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Aug 2013 10:51:38 -0700 Message-Id: <4C09F015-33D1-45D0-9898-E69305071D47@earthlink.net> To: Glen Kent Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec790f550e752dbf8479d3aa7786885a8ca8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 50.168.24.201 Cc: OSPF List Subject: Re: [OSPF] 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: Fri, 02 Aug 2013 17:51:56 -0000 Glen, I don't know if this will get to the general mailing list, so = you can forward if you want. First, the most general rule is to be secure all components must = be "Trusted". Within the internet this is very difficult unless.. Within Ethernet, within OSPF, we have two major bottlenecks; the = DR and the BDR. Thus for a new entity to become a DRother BOTH of those = must authenticate it. Thus no vulnerability exists if authentication support exists = and this future possible DRother fails authentication. Mitchell Erblich =09 Begin forwarded message: > From: Glen Kent > Subject: [OSPF] OSPF - Owning the Routing Table Attack > Date: August 2, 2013 9:41:01 AM PDT > To: "ospf@ietf.org" >=20 > Hi, >=20 > Does anybody have details on what this OSPF vulnerability is? >=20 > https://www.blackhat.com/us-13/briefings.html#Nakibly > Glen >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf Begin forwarded message: > From: Uma Chunduri > Subject: Re: [OSPF] OSPF - Owning the Routing Table Attack > Date: August 2, 2013 10:19:23 AM PDT > To: Glen Kent , "ospf@ietf.org" >=20 > Remembered comments about this in SAAG. > =20 > If authentication shared secrets are compromised (insider attack) you = can envision all sorts of issues. > =20 > If this is still considered serious consider changing keys or use a = key management protocol (hope there will be one defined) to do this = periodically! > =20 > --=20 > Uma C. >=20 > =20 >=20 > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf = Of Glen Kent > Sent: Friday, August 02, 2013 9:41 AM > To: ospf@ietf.org > Subject: [OSPF] OSPF - Owning the Routing Table Attack >=20 > Hi, >=20 > Does anybody have details on what this OSPF vulnerability is? >=20 > https://www.blackhat.com/us-13/briefings.html#Nakibly > Glen >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf Begin forwarded message: > From: Uma Chunduri > Subject: Re: [OSPF] OSPF - Owning the Routing Table Attack > Date: August 2, 2013 10:19:23 AM PDT > To: Glen Kent , "ospf@ietf.org" >=20 > Remembered comments about this in SAAG. > =20 > If authentication shared secrets are compromised (insider attack) you = can envision all sorts of issues. > =20 > If this is still considered serious consider changing keys or use a = key management protocol (hope there will be one defined) to do this = periodically! > =20 > --=20 > Uma C. >=20 > =20 >=20 > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf = Of Glen Kent > Sent: Friday, August 02, 2013 9:41 AM > To: ospf@ietf.org > Subject: [OSPF] OSPF - Owning the Routing Table Attack >=20 > Hi, >=20 > Does anybody have details on what this OSPF vulnerability is? >=20 > https://www.blackhat.com/us-13/briefings.html#Nakibly > Glen >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From mjbarnes@cisco.com Fri Aug 2 10:56:29 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 4FA4211E8113 for ; Fri, 2 Aug 2013 10:56:29 -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 qaWgYzPmpKeb for ; Fri, 2 Aug 2013 10:56:25 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB9011E80EE for ; Fri, 2 Aug 2013 10:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1259; q=dns/txt; s=iport; t=1375466185; x=1376675785; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=hOs4T4VWoJP1qP27CbDKroESnv36z5EB9LsSPkeHvTU=; b=E/SIaI7RGrir8Qf9JfDwHMS9T0fBgY+kcM9pgWntlCSoril4dOFc5xKl ZQiMpl51qq2eFHP9BMrxsrGlgdfZWzobZsxHBoz7RugiW2F6U7Gvnf2Qz nI/ulGQIt+ZujHmX/nR2hA3tzlNTmNrgmAIldh5mF1beWFZbEbtCmSi8Q w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAFTy+1GrRDoH/2dsb2JhbABagwY1Ab9TgR0WdIIkAQEBBAEBATU2ChELGAkWDwkDAgECARUwEwYCAQGICw25EJAfFoN3A4kqjjWBKoR6iyqDNxw X-IronPort-AV: E=Sophos;i="4.89,802,1367971200"; d="scan'208";a="88219700" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 02 Aug 2013 17:56:24 +0000 Received: from [10.21.84.168] (sjc-vpn4-1193.cisco.com [10.21.84.168]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r72HuNJE005377 for ; Fri, 2 Aug 2013 17:56:23 GMT Message-ID: <51FBF2C7.2080706@cisco.com> Date: Fri, 02 Aug 2013 10:56:23 -0700 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: ospf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OSPF] 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: Fri, 02 Aug 2013 17:56:29 -0000 I don't think he has discovered anything revolutionary. It has been widely known for many years that if someone has control of a router, or links which are not protected by authentication, that there are many forms of mischief (e.g. insider attacks). I found this slide from an IETF presentation in 1998 which lists a number of previous papers: https://www.ietf.org/proceedings/46/slides/ospf-sec/tsld003.htm Some of the following slides explain a few possible exploits, all of which are "insider" attacks. There is a well known IETF document which lists a number of OSPF vulnerabilities, however it is not a complete list: http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.txt So I don't find this "briefing" very interesting. What would be interesting to me, would be a way to attack OSPF when SHA-256 authentication is deployed, beyond the known replay attacks. Regards, Michael On 08/02/2013 09:41 AM, Glen Kent wrote: > Hi, > > Does anybody have details on what this OSPF vulnerability is? > > https://www.blackhat.com/us-13/briefings.html#Nakibly > > Glen > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From uma.chunduri@ericsson.com Fri Aug 2 11:06: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 4953311E8127 for ; Fri, 2 Aug 2013 11:06:50 -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 VJCYICRMqvyx for ; Fri, 2 Aug 2013 11:06:43 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8304311E8101 for ; Fri, 2 Aug 2013 11:06:15 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-78-51fbf511bfca Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 3B.92.31362.115FBF15; Fri, 2 Aug 2013 20:06:10 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Fri, 2 Aug 2013 14:06:09 -0400 From: Uma Chunduri To: Michael Barnes , "ospf@ietf.org" Thread-Topic: [OSPF] OSPF - Owning the Routing Table Attack Thread-Index: AQHOj58i/36FKErcrkCmoibJVlArvpmCdwOA//++I6A= Date: Fri, 2 Aug 2013 18:06:09 +0000 Message-ID: <1B502206DFA0C544B7A604691520086317449920@eusaamb105.ericsson.se> References: <51FBF2C7.2080706@cisco.com> In-Reply-To: <51FBF2C7.2080706@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.53.73.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyuXRPiK7Q19+BBqe6BSwWr3vFYtFy7x67 A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVx8rVhQTNzxbd1TWwNjJuZuhg5OSQETCSa ZmxkhbDFJC7cW8/WxcjFISRwlFFi/+2/LBDOMkaJG9P6wDrYBPQkPk79yQ5iiwh4SOw7v4IZ xBYWsJL4sH4BUA0HUNxa4vl8P4gSK4ntsxvAFrAIqEgcvnAOzOYV8JXYc2862BghgXyJh7tO gY3hFNCUeLv/DRuIzQh00PdTa8DWMguIS9x6Mh/qaAGJJXvOM0PYohIvH/+DekBBYmvbdqh6 HYkFuz+xQdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGLkKC1OLctNNzLc xAiMhWMSbI47GBd8sjzEKM3BoiTOu0HvTKCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxslm j+K4Jz6XKNTlmHL8ouT3R1neQR7sx7qZAn+4X7xunbWTM/kRW2gWu3OASI5L+ISlCoLlLAte skZuvFF2reLu9/zS67PUN83L+FWiEfH/s1Hah7DfC1gEtvx2SfvyK+PS2sj7iXf+1B/yz555 Xn/18toGS+8bkQbafPN5qn+b/NAy0A06r8RSnJFoqMVcVJwIAO4KxR5TAgAA Subject: Re: [OSPF] 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: Fri, 02 Aug 2013 18:06:50 -0000 >>What would be interesting to me, would be a way to attack OSPF when=20 >>SHA-256 authentication is deployed, beyond the known replay attacks. Doesn't matter what auth algo is used for their work; if same key is used=20 on all interfaces and it is compromised/got access some how (insider)=20 - It's not hard to create the issues the posting documented. $0.02 -- Uma C. From orhanergun81@gmail.com Fri Aug 2 11:48:10 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 1C94821F9A1E for ; Fri, 2 Aug 2013 11:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] 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 N8EHgr9jsMhO for ; Fri, 2 Aug 2013 11:48:09 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id CEEA521F9A2A for ; Fri, 2 Aug 2013 11:47:58 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id c11so813632wgh.20 for ; Fri, 02 Aug 2013 11:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=rf8rghd2BQgS9O8Z5+wLn/wqEJreHpE6wJBvdGkkzoo=; b=yx6AH7rmzKJrT+kvmLVyya7czbqwssCaaunz/obpeguQYGv0WxlG9HdA1nYMp37SyE hRFF17ah4vHznnX5dxZRxplBfM9Tvy/N0xI9DOU/y96K446tjgRzERmiuieRiym9iWFV aou+eCREHMeOprG97hjN2U+CsItZdAMpk0tGLXKXLwFy2cBSoQpAclSpLlmdCg5lrgEV 9QL2K7hEdQCh5YXJZZb1z7gSdZo/EmA2Zlh6+uT8FXwseFDcHds8vQVGNs/kwAzsx80n oD0TPsXC5273uwqjWuNq04U/JVSvhADFb0AN7Xb1+6DPluEUaC10173xtt6TmrjOiZeE u/rA== X-Received: by 10.194.170.227 with SMTP id ap3mr5947044wjc.40.1375469277476; Fri, 02 Aug 2013 11:47:57 -0700 (PDT) Received: from [192.168.1.88] ([89.211.200.229]) by mx.google.com with ESMTPSA id jf9sm5035365wic.5.2013.08.02.11.47.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 11:47:57 -0700 (PDT) References: <51FBF2C7.2080706@cisco.com> In-Reply-To: <51FBF2C7.2080706@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9A334) From: =?utf-8?Q?Orhan_Erg=C3=BCn?= Date: Fri, 2 Aug 2013 21:47:55 +0300 To: Michael Barnes Cc: "ospf@ietf.org" Subject: Re: [OSPF] 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: Fri, 02 Aug 2013 18:48:10 -0000 =C4=B0 totaly agree wit Michael its well known and this attack even can be d= one from several hops away .=20 Best Regards, Orhan ERGUN On 2 A=C4=9Fu 2013, at 20:56, Michael Barnes wrote: > I don't think he has discovered anything revolutionary. It has been widely= known for many years that if someone has control of a router, or links whic= h are not protected by authentication, that there are many forms of mischief= (e.g. insider attacks). >=20 > I found this slide from an IETF presentation in 1998 which lists a number o= f previous papers: > https://www.ietf.org/proceedings/46/slides/ospf-sec/tsld003.htm >=20 > Some of the following slides explain a few possible exploits, all of which= are "insider" attacks. >=20 > There is a well known IETF document which lists a number of OSPF vulnerabi= lities, however it is not a complete list: > http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.txt >=20 > So I don't find this "briefing" very interesting. What would be interestin= g to me, would be a way to attack OSPF when SHA-256 authentication is deploy= ed, beyond the known replay attacks. >=20 > Regards, > Michael >=20 > On 08/02/2013 09:41 AM, Glen Kent wrote: >> Hi, >>=20 >> Does anybody have details on what this OSPF vulnerability is? >>=20 >> https://www.blackhat.com/us-13/briefings.html#Nakibly >>=20 >> Glen >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 From mjbarnes@cisco.com Fri Aug 2 12:05: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 9043211E8136 for ; Fri, 2 Aug 2013 12:05: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=[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 EqUK87BAb+BL for ; Fri, 2 Aug 2013 12:05:40 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEBF11E80EC for ; Fri, 2 Aug 2013 12:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=803; q=dns/txt; s=iport; t=1375470340; x=1376679940; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zRG97VFt8pPPZUY3D1PQ/xKHK4c2bQf1zYk3kRgcXW0=; b=D6MwrZSSu3XQNN00X1Zobl+WWRJ4MiMeRLfczaJiQ8m+IP0OrZpSvg1A cXE/fNGPD03sxVNyOCtlaogAMkyc6tUrUYEnqxUpxiVfhkqfZyb8N5yzQ +TMx+z3feKshfhkSJEAe7Px7b6SCaL2j4xCG8VNsyH7wjvQULQHmjrbph Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAAIC/FGrRDoG/2dsb2JhbABagwY2vGKCcIEeFnSCJAEBAQQ4QRALGAklDwJGBg0BBwEBiAu5GJAYB4QNA4kqjjWGJIsqgzcc X-IronPort-AV: E=Sophos;i="4.89,803,1367971200"; d="scan'208";a="88287030" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 02 Aug 2013 19:05:38 +0000 Received: from [10.21.84.168] (sjc-vpn4-1193.cisco.com [10.21.84.168]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r72J5YUF023970; Fri, 2 Aug 2013 19:05:36 GMT Message-ID: <51FC02FD.90109@cisco.com> Date: Fri, 02 Aug 2013 12:05:33 -0700 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Uma Chunduri References: <51FBF2C7.2080706@cisco.com> <1B502206DFA0C544B7A604691520086317449920@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A604691520086317449920@eusaamb105.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" Subject: Re: [OSPF] 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: Fri, 02 Aug 2013 19:05:45 -0000 On 08/02/2013 11:06 AM, Uma Chunduri wrote: >>> What would be interesting to me, would be a way to attack OSPF when >>> SHA-256 authentication is deployed, beyond the known replay attacks. > > Doesn't matter what auth algo is used for their work; if same key is used > on all interfaces and it is compromised/got access some how (insider) > - It's not hard to create the issues the posting documented. If the key is compromised then what's the difference if no key is used? The reason I mentioned SHA-256 is that it is currently recommended algorithm to use. But you're right, it really doesn't matter what the algorithm is. I should have stated it differently. Anyway, I think we agree that a new insider attack is not interesting because it's just one more of a known list. -M From equinox@diac24.net Sun Aug 4 06:06: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 7C80721F99B7 for ; Sun, 4 Aug 2013 06:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 0XUwbWsgF9at for ; Sun, 4 Aug 2013 06:06:19 -0700 (PDT) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B4521F99A1 for ; Sun, 4 Aug 2013 06:06:19 -0700 (PDT) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V5y0m-0003xv-CW; Sun, 04 Aug 2013 15:06:16 +0200 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1V5y0Z-000Nuw-B6; Sun, 04 Aug 2013 15:06:05 +0200 Date: Sun, 4 Aug 2013 15:06:03 +0200 From: David Lamparter To: Glen Kent Message-ID: <20130804130603.GV67612@jupiter.n2.diac24.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "ospf@ietf.org" Subject: [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: Sun, 04 Aug 2013 13:06:20 -0000 On Fri, Aug 02, 2013 at 10:11:01PM +0530, Glen Kent wrote: > Does anybody have details on what this OSPF vulnerability is? > > https://www.blackhat.com/us-13/briefings.html#Nakibly As people may have noticed by now (the embargo on 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. As such, this attack is implementable from any router in an OSPF area against any other router in the OSPF. (Quite honestly, IMHO this is seriously far fetched. If your control plane got compromised this far you have other problems.) While Quagga is unaffected by this, we've implemented a warning. We're also considering dropping the LSA outright, but I'm somewhat split on that (tilted towards dropping). I'd be interested if the WG has comments on that? -David From acee.lindem@ericsson.com Sun Aug 4 19:28:35 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 209C421E80C9 for ; Sun, 4 Aug 2013 19:28:35 -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 84j9n16lN4VN for ; Sun, 4 Aug 2013 19:28:24 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 99DB421E80C7 for ; Sun, 4 Aug 2013 19:28:21 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-5f-51ff0dc4fe38 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 5A.AC.31362.4CD0FF15; Mon, 5 Aug 2013 04:28:20 +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; Sun, 4 Aug 2013 22:28:20 -0400 From: Acee Lindem To: David Lamparter , Glen Kent Thread-Topic: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) Thread-Index: AQHOkYNzswj2Iqvcb0CzsjXPhXr4xQ== Date: Mon, 5 Aug 2013 02:28:19 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4702FE6F29@eusaamb101.ericsson.se> In-Reply-To: <20130804130603.GV67612@jupiter.n2.diac24.net> 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: text/plain; charset="us-ascii" Content-ID: <79EFAB8D2DA48049AFC7471C162EA345@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXSPt+4R3v+BBjt7TS3WNG5gtthz4j2L Rcu9e+wOzB5f9kp57Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZjU+mMBZs563Y+tCmgfEv VxcjJ4eEgIlE//55zBC2mMSFe+vZuhi5OIQEjjJKHJi0jBXCWcYosXHWchaQKjYBHYnnj/6B dYgIeEos7/vEBGIzCyhLPO5aDdTNwSEsEC0x6UIIREmMxJILbxkhbD2J6XfWgNksAioS93/9 ZQIp5xXwldg0vwQkzClgLTF5wVs2EJsR6J7vp9ZATReXuPVkPhPEnQISS/ach7pZVOLl43+s ILYo0Pi2Y2fYIeLKEkue7GeB6NWRWLD7ExuEbS3xZ94NRghbW2LZwtdgc3gFBCVOznzCMoFR fBaSdbOQtM9C0j4LSfssJO0LGFlXMXKUFqeW5aYbGW5iBMbYMQk2xx2MCz5ZHmKU5mBREufd oHcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjoUUrRROm6jU+1nqz794FAYaqx/c0tt3I nrBz/+9N7XIWRbudBc6pn/9o0jnnbuvkyP0G8SfS5p+dq2fjH/qC5e8tfrOj8eynXPL/nXNP qz8yn/kmm/m8ma+PfJRmMzCa82ljDU/M7uOzFua25ukdu/zB+9s2zddsWbN3VabUO69u2vF9 knzlYyWW4oxEQy3mouJEAPfAceN/AgAA 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: Mon, 05 Aug 2013 02:28:35 -0000 On 8/4/13 6:06 AM, "David Lamparter" wrote: >On Fri, Aug 02, 2013 at 10:11:01PM +0530, Glen Kent wrote: >> Does anybody have details on what this OSPF vulnerability is? >>=20 >> https://www.blackhat.com/us-13/briefings.html#Nakibly > >As people may have noticed by now (the embargo on 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. As such, this >attack is implementable from any router in an OSPF area against any >other router in the OSPF. > >(Quite honestly, IMHO this is seriously far fetched. If your control >plane got compromised this far you have other problems.) I agree that once the OSPF control plane is open, you are susceptible to many attacks. However, this attack is a bit more insidious than most since the actual OSPF router corresponding to the link state ID will most likely not recognize the LSA as self-originated and re-originate a more recent version when the 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. > >While Quagga is unaffected by this, we've implemented a warning. We're >also considering dropping the LSA outright, but I'm somewhat split on >that (tilted towards dropping). I'd be interested if the WG has >comments on that? I can't speak for the WG but my implementation will skip the LSA in the Link-State Update packet. Thanks, Acee > > >-David >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Mon Aug 5 10:47:41 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 643FF11E810C for ; Mon, 5 Aug 2013 10:47:41 -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 sNH39pDPt2JU for ; Mon, 5 Aug 2013 10:47:36 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id D9DE221F9F01 for ; Mon, 5 Aug 2013 10:47:35 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-b3-51ffe5367838 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9E.95.31362.635EFF15; Mon, 5 Aug 2013 19:47:35 +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, 5 Aug 2013 13:47:34 -0400 From: Acee Lindem To: "ospf@ietf.org" Thread-Topic: OSPF WG Minutes Thread-Index: AQHOkgPd9gQEIWe66Ea8AldlIa5n8w== Date: Mon, 5 Aug 2013 17:47:34 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4702FE8E0D@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.135] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE4702FE8E0Deusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXSPt6750/+BBrsfclq03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLfbu9gKrnFWXGxYytTAeIWji5GTQ0LARKL5zmcmCFtM4sK9 9WxdjFwcQgJHGSU2Hn3CCOEsY5R4sP04WBWbgI7E80f/mEFsEQFliS17+9lAbGEBSYlVmy+y Q8TlJE7+WMsCYetJzP/xFyzOIqAisXfTP7A4r4CvxPQfW8F6GYE2fz+1Bmw+s4C4xK0n86Eu EpBYsuc8M4QtKvHy8T9WEFsUaGbbsTPsEHFlie9zHgHN5ADqzZeYvTIdYrygxMmZT1gmMArP QjJ1FkLVLCRVECU6Egt2f2KDsLUlli18zQxjnznwmAnCtpaY0TWFEVnNAkaOVYwcpcWpZbnp RoabGIFxckyCzXEH44JPlocYpTlYlMR5N+idCRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA ON+10jfm9V3lxNhZc8PVNWLe3DHNUv7C+lGK+dW6F7WSy3l/eyyfYHWL9ax24jebpk0Wuw/P 1rmo+Ua26+aWksI3u1bd6pT3++/16ezDRX4FKwrM7+2O0fFbN/t81DZVQweea8JK0WWX901b 8N/mYtH+tevS41//PcHAZPAu7kbu5jMytUqXspRYijMSDbWYi4oTAe3UvSVhAgAA Subject: [OSPF] OSPF WG Minutes 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, 05 Aug 2013 17:47:41 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE4702FE8E0Deusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have posted the IETF 87 OSPF WG minutes. They can be found here: http://w= ww.ietf.org/proceedings/87/minutes/minutes-87-ospf Thanks to Yi Yang for being the scribe. Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE4702FE8E0Deusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <8974F2240E283E4C9F6A598F16A6694E@ericsson.com> Content-Transfer-Encoding: quoted-printable
I have posted the IETF 87 OSPF WG minutes. They can be found here:&nbs= p;ht= tp://www.ietf.org/proceedings/87/minutes/minutes-87-ospf
Thanks to Yi Yang for being the scribe. 
Acee 
--_000_94A203EA12AECE4BA92D42DBFFE0AE4702FE8E0Deusaamb101erics_-- From gnakibly@yahoo.com Mon Aug 5 14:04: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 8DA1321F9EE5 for ; Mon, 5 Aug 2013 14:04:02 -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 HWQuJnWnNg8H for ; Mon, 5 Aug 2013 14:03:57 -0700 (PDT) Received: from nm43-vm7.bullet.mail.bf1.yahoo.com (nm43-vm7.bullet.mail.bf1.yahoo.com [216.109.114.238]) by ietfa.amsl.com (Postfix) with ESMTP id 70ED321F9F7A for ; Mon, 5 Aug 2013 14:03:57 -0700 (PDT) Received: from [98.139.212.148] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 21:03:55 -0000 Received: from [98.139.212.215] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 21:03:55 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 21:03:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 829709.74858.bm@omp1024.mail.bf1.yahoo.com Received: (qmail 16690 invoked by uid 60001); 5 Aug 2013 21:03:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375736635; bh=lNR8G5rUttJErlagncX2noAM0E/5Jm84LiPVSxB+4ts=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MoGcGKaBpmfl4298t2iuCIUERqpEbei+OWvQ4O8fgAKx6v+7kGWj3PlmmZyb0DVjgHpPWFNyZa1Y8b1WIFxdGqzjO2SE7r9xgplUMC+EJYFGi7yoY5+njoGZC5naAFbzoB/aJZx6YrMVZiwMJjTG8tJDuczHZQFY/jsgXz6DwUM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ijfFxOyPb9+6nO9O6ke2U+9kfgSSRrAP1qtD7hPirqFWzra2ZNs45ITr7Et6Xn9LPbtzX+M9++7TiY6KZJAy6hOjlaFbreL6eKAZumbj/iOKb/lkEQjVMV0ggQ1CkxlDxkkOG5KJE7ZDrmun47vJcu93rrr+g1J2C/uUOS8RoxA=; X-YMail-OSG: uPY6zmEVM1mb7fSZ1395TIu3nKP5D_rrbtkrR719AFghlL4 45bP8v0noWZaa3aSIiWZFZ5B5gQJj9pXkFyMqWUHbpFjdyQ0ccB5.D7I_7ku HMUWYI_zEbRSQlp_blIgY_bFZiA_Rde4w3Bk8q8406JAlAxUxpmv0kkt0Yrx mZDB1PT2FAHqBIS5a5zjEtQVrqW6.yQYgvffcnW7hYbq2mSoDz3.iUhAlUAX d9GHA7O97ReTi7MQclMoIXOx9oZeEyEdfy1FQv8Hf0HjlKjJRWBHqAY0pGgr RoW6a63l3nopa_s.1zRQLbT3KOCUYtyy04LWMBVNQE4fGcAwWlE6yWkchzkB Icf8WNT8G5BovgImDZJw_G37u0zHCidz0.SNOyy3ncgPYD4WUnakKqqSFtmR fvtpypARNN.OPewDWN7XTxBgsjDvnPtiWeS2MecZ1_57Kf2w2qOL_6Fi0YJ1 ClVkEEYVVRnV1GakdpZ8av3NRn._e.8T0BQ2gNJv0OYeutsE.Y0f6oNkZZS9 I6jUpKRf82sqdbcV9DNb_Q0IQh3neFmabl.VMlkGq9L5SaD8OnSJjI64sw1t xH_iMVPEAQHy4dtjSAbzdi0nIFGhQit4DKo4ZC6A9WSjHLuFJ_wlOELFPtMp ze8_zq1pcntrAmYoIP_VtJjvjtdmcNjbadT.av3wXfY4Z7oxu9BCxDZ0.4tV Zlq25sfqBg_zC.yOX_47YGBqUBc137Za36km47wSQtl9TCoaGYTfx9qHCg4C fTdas4AOv.Ra2xHA6VFCzFQ.G.APctayUDhP_YKmlUsh.maJmkiElWLyunnh wg8z6U1rYM2XwkzBs7pGbyRnMCcFXcQ-- Received: from [85.64.247.76] by web165005.mail.bf1.yahoo.com via HTTP; Mon, 05 Aug 2013 14:03:55 PDT X-Rocket-MIMEInfo: 002.001, SGkgYWxsLApNeSBuYW1lIGlzIEdhYmkuIEkgYW0gdGhlIHJlc2VhcmNoZXIgd2hvIHByZXNlbnRlZCB0aGUgbmV3IGF0dGFjayBhdCBCbGFjayBIYXQgbGFzdCB3ZWVrLiBJIGhhdmUgbm90aWNlZCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBhbmQgSSB3b3VsZCBiZSBoYXBweSB0byB0cnkgdG8gY2xhcmlmeSBob3cgdGhlIGF0dGFjayBpcyBkaWZmZXJlbnQgZnJvbSBrbm93biBvbmVzLsKgCkluZGVlZCB0aGUgYXR0YWNrIGFzc3VtZXMgdGhhdCB0aGUgYXR0YWNrZXIgaXMgYW4gaW5zaWRlciwgbWVhbmkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.152.567 References: <20130804130603.GV67612@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FE6F29@eusaamb101.ericsson.se> Message-ID: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> Date: Mon, 5 Aug 2013 14:03:55 -0700 (PDT) From: Gabi Nakibly To: Acee Lindem , David Lamparter , Glen Kent In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4702FE6F29@eusaamb101.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 Reply-To: Gabi Nakibly List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:04:02 -0000 Hi all,=0AMy name is Gabi. I am the researcher who presented the new attack= at Black Hat last week. I have noticed the discussion on the list and I wo= uld be happy to try to clarify how the attack is different from known ones.= =A0=0AIndeed the attack assumes that the attacker is an insider, meaning th= at the attacker has already gained control of one of the router within the = AS. I agree 100% that once an attacker is an insider he can already do all = sorts of attacks that can harm the network and indeed a few past works have= already reported on this. Nonetheless, =A0the crux of the new attack,=A0as= Acee has already pointed out, is that an attacker is now able to falsify a= n LSA on behalf of another router while evading the fight-back mechanism. T= his new capability allows an attacker to *persistently* and *stealthily* su= bvert the LSA DB of other routers that install the false LSA and thereby al= tering their routing tables. This gives rise to a new class of attacks that= in my opinion have not existed before and, in many times, are more desirab= le for an attacker (due to their stealth and persistence).=0ATo my best kno= wledge, no other general technique to stealthily evade fight back is known.= The only general attack technique to evade fight back is=A0periodic inject= ion (flooding=A0false LSAs at a rate higher thanone every MinLSInterval) = =A0presented in=A0http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.tx= t=A0in Section 4.1.3.1. However, =A0using such technique the attack is hard= ly stealthy.=0A=0ABTW, I have also presented in the past another general te= chnique to evade fight back called 'Disguised LSA'. It is described in=A0ht= tps://www.cs.technion.ac.il/people/gnakibly/online-publications/PersistentO= SPF.pdf=A0in Section 4.2.=0A=0AI would appreciate your continued feedback o= n the new attack.=0A=0AThanks,=0AGabi=0A=0A>_______________________________= _=0A> From: Acee Lindem =0A>To: David Lamparter <= equinox@diac24.net>; Glen Kent =0A>Cc: "ospf@ietf.org= " =0A>Sent: Monday, August 5, 2013 5:28 AM=0A>Subject: Re: = [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack= )=0A> =0A>=0A>=0A>=0A>On 8/4/13 6:06 AM, "David Lamparter" wrote:=0A>=0A>>On Fri, Aug 02, 2013 at 10:11:01PM +0530, Glen Kent wro= te:=0A>>> Does anybody have details on what this OSPF vulnerability is?=0A>= >> =0A>>> https://www.blackhat.com/us-13/briefings.html#Nakibly=0A>>=0A>>As= people may have noticed by now (the embargo on providing details has=0A>>e= xpired as the talk was presented), this issue consists of Router LSAs=0A>>w= here the Router ID is different from the Link State ID.=A0 As such, this=0A= >>attack is implementable from any router in an OSPF area against any=0A>>o= ther router in the OSPF.=0A>>=0A>>(Quite honestly, IMHO this is seriously f= ar fetched.=A0 If your control=0A>>plane got compromised this far you have = other problems.)=0A>=0A>I agree that once the OSPF control plane is open, y= ou are susceptible to=0A>many attacks. However, this attack is a bit more i= nsidious than most since=0A>the actual OSPF router corresponding to the lin= k state ID will most likely=0A>not recognize the LSA as self-originated and= re-originate a more recent=0A>version when the malformed one is received. = Hence, the malicious LSA will=0A>remain in the routing domain and, dependin= g upon the OSPF implementation,=0A>could result in traffic being redirected= .=0A>=0A>>=0A>>While Quagga is unaffected by this, we've implemented a warn= ing.=A0 We're=0A>>also considering dropping the LSA outright, but I'm somew= hat split on=0A>>that (tilted towards dropping).=A0 I'd be interested if th= e WG has=0A>>comments on that?=0A>=0A>I can't speak for the WG but my imple= mentation will skip the LSA in the=0A>Link-State Update packet.=0A>=0A>Than= ks,=0A>Acee=0A>=0A>=0A>>=0A>>=0A>>-David=0A>>______________________________= _________________=0A>>OSPF mailing list=0A>>OSPF@ietf.org=0A>>https://www.i= etf.org/mailman/listinfo/ospf=0A>=0A>______________________________________= _________=0A>OSPF mailing list=0A>OSPF@ietf.org=0A>https://www.ietf.org/mai= lman/listinfo/ospf=0A>=0A>=0A> From equinox@diac24.net Tue Aug 6 06:50:10 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 3A4B521F9EED for ; Tue, 6 Aug 2013 06:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, 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 UNavuWFYg4mO for ; Tue, 6 Aug 2013 06:50:09 -0700 (PDT) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C25521F9CAC for ; Tue, 6 Aug 2013 06:50:09 -0700 (PDT) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V6heK-0004m7-DZ for ospf@ietf.org; Tue, 06 Aug 2013 15:50:08 +0200 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1V6he7-0035cm-Gs for ospf@ietf.org; Tue, 06 Aug 2013 15:49:57 +0200 Date: Tue, 6 Aug 2013 15:49:55 +0200 From: David Lamparter To: ospf@ietf.org Message-ID: <20130806134954.GJ95257@jupiter.n2.diac24.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? 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, 06 Aug 2013 13:50:10 -0000 Hi ospf WG, looking at the Extended LSA draft from the various use cases, I believe it would be advantageous to repurpose the topmost two bits of the TLV type to indicate what should happen if the TLV is not supported by a router. I'm thinking of 3-4 possible handlings: (these all only apply to parent TLVs or LSAs that specify a route in some way, e.g. currently Inter/Intra/AS-Ext-Prefix LSAs. Though the first two make sense in a generic way.) 00 - ignore TLV this can be used for all "hint" TLVs, stuff like maybe communicating the origin ASN for external routes or whatever you can dream up. 01 - ignore parent on calculating SPF, completely ignore the resulting route. This is useful for MT-OSPF (if it ever happens), to be used on a MT-ID TLV with an MT-ID != 0. Basically, non-MT routers can ignore all nonzero MT topologies this way. 10 - strong unreachable mark the route's destination prefix as unreachable and install a corresponding blackhole/... route. This is the right thing to do on SADR routes when they hit a non-SADR router. Even if we have the same prefix reachable on a non-SADR route with a lower metric, we can't ensure that it's loop-free for a particular source address. 11 - weak unreachable (?) treat the route as "unreachable", adding it to the SPF result as such, if there is no shorter path to the same prefix so far. This is probably the least useful type, I can only come up with something like "route that requires special encapsulation (tunnel?)" - no idea on the reality here. Note that this is supposed to work in conjunction with other ways of communicating per-router capabilities, e.g. Router Information LSAs. A router may well need to take a different action when, on calculating, it notices that it passed by a router without support for feature XYZ. Since that applies to routers that *do* implement a particular extension, the exact behaviour for this needs to be specified in that extension. Comments? -David From acee.lindem@ericsson.com Tue Aug 6 07:16: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 5E19A21F9C37 for ; Tue, 6 Aug 2013 07:16: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 Sq8gYT0o5E8N for ; Tue, 6 Aug 2013 07:16:13 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D5DC921F9A4B for ; Tue, 6 Aug 2013 07:16:12 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-c4-5201052c70e7 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 8F.63.13034.C2501025; Tue, 6 Aug 2013 16:16:12 +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; Tue, 6 Aug 2013 10:16:11 -0400 From: Acee Lindem To: David Lamparter Thread-Topic: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? Thread-Index: AQHOkqwAjkxiEC+2aEOyPevoodJ9h5mIfLUA Date: Tue, 6 Aug 2013 14:16:10 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4702FEA381@eusaamb101.ericsson.se> References: <20130806134954.GJ95257@jupiter.n2.diac24.net> In-Reply-To: <20130806134954.GJ95257@jupiter.n2.diac24.net> 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: <4F36694EBB188A418FB3698A641CD204@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXSPn64OK2OQQc9tBYs1jRuYLVru3WN3 YPL4slfKY8mSn0wBTFFcNimpOZllqUX6dglcGfu3NrAW3BOpmLyqhbWBcbtAFyMnh4SAicTJ 3uOsELaYxIV769m6GLk4hASOMkosW3mPEcJZxihx+el6JpAqNgEdieeP/jGD2CICGhJtb1cA xTk4mAVUJR4fZQMJCwvESHRvvsQOURIrMaXpNyuEbSTR/GYaWCuLgIrEtzmrwGp4BXwlJh7u YwSxhQSsJLZN+AAW5xSwlmjvbgLrZQQ67vupNWAnMAuIS9x6Mp8J4mgBiSV7zjND2KISLx// g3pGWWLJk/0sEPU6Egt2f2KDsK0ljr1Ywgxha0ssW/iaGeIGQYmTM5+wTGAUn4VkxSwk7bOQ tM9C0j4LSfsCRtZVjBylxalluelGBpsYgTF1TIJNdwfjnpeWhxilOViUxHlX6Z0JFBJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cDYuUbQ3I+l8WuGyp0VP79Wiq7Yzdre8PhMZ4/nQ27/6xoX gty3ZeWzPvgmH5Q2/Uf4DcO6yr+rRcIfJD/sFSn4lLx1Q4ez7hyWN+vKXBempZcE5h1SKtT2 YLHWPPk0M8Uv1ldeKHT5x3dxnmISBeJe0zW8NO2KBPNvfhFd1RnBkJJ5hHt/oRJLcUaioRZz UXEiAIQ5bBx3AgAA Cc: "" Subject: Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? 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, 06 Aug 2013 14:16:18 -0000 Hi David, I don't think this is a good idea at all. An implementation can only deal w= ith the TLVs it understands so the ignore options don't make sense.=20 If the other actions are necessary, we'd be better served with a more defin= itive use case and encoding than reusing TLV bits.=20 Acee=20 On Aug 6, 2013, at 9:49 AM, David Lamparter wrote: > Hi ospf WG, >=20 >=20 > looking at the Extended LSA draft from the various use cases, I believe > it would be advantageous to repurpose the topmost two bits of the TLV > type to indicate what should happen if the TLV is not supported by a > router. I'm thinking of 3-4 possible handlings: >=20 > (these all only apply to parent TLVs or LSAs that specify a route in > some way, e.g. currently Inter/Intra/AS-Ext-Prefix LSAs. Though the > first two make sense in a generic way.) >=20 > 00 - ignore TLV > this can be used for all "hint" TLVs, stuff like maybe communicating > the origin ASN for external routes or whatever you can dream up. >=20 > 01 - ignore parent > on calculating SPF, completely ignore the resulting route. This is > useful for MT-OSPF (if it ever happens), to be used on a MT-ID TLV > with an MT-ID !=3D 0. Basically, non-MT routers can ignore all nonzero > MT topologies this way. >=20 > 10 - strong unreachable > mark the route's destination prefix as unreachable and install a > corresponding blackhole/... route. This is the right thing to do on > SADR routes when they hit a non-SADR router. Even if we have the same > prefix reachable on a non-SADR route with a lower metric, we can't > ensure that it's loop-free for a particular source address. >=20 > 11 - weak unreachable (?) > treat the route as "unreachable", adding it to the SPF result as such, > if there is no shorter path to the same prefix so far. This is > probably the least useful type, I can only come up with something like > "route that requires special encapsulation (tunnel?)" - no idea on the > reality here. >=20 > Note that this is supposed to work in conjunction with other ways of > communicating per-router capabilities, e.g. Router Information LSAs. > A router may well need to take a different action when, on calculating, > it notices that it passed by a router without support for feature XYZ. > Since that applies to routers that *do* implement a particular > extension, the exact behaviour for this needs to be specified in that > extension. >=20 > Comments? >=20 >=20 > -David > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From equinox@diac24.net Tue Aug 6 07:22:06 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 A436F21F9DF6 for ; Tue, 6 Aug 2013 07:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.086, 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 q2TBYXY5WUZ3 for ; Tue, 6 Aug 2013 07:22:06 -0700 (PDT) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A66621F938E for ; Tue, 6 Aug 2013 07:22:05 -0700 (PDT) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V6i9C-0007Yn-GR; Tue, 06 Aug 2013 16:22:02 +0200 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1V6i90-0037UL-1C; Tue, 06 Aug 2013 16:21:51 +0200 Date: Tue, 6 Aug 2013 16:21:49 +0200 From: David Lamparter To: Acee Lindem Message-ID: <20130806142149.GK95257@jupiter.n2.diac24.net> References: <20130806134954.GJ95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA381@eusaamb101.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4702FEA381@eusaamb101.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "" Subject: Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? 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, 06 Aug 2013 14:22:06 -0000 On Tue, Aug 06, 2013 at 02:16:10PM +0000, Acee Lindem wrote: > I don't think this is a good idea at all. An implementation can only > deal with the TLVs it understands so the ignore options don't make > sense. > If the other actions are necessary, we'd be better served with a more > definitive use case and encoding than reusing TLV bits. Section 3 of the draft states: [...] Unrecognized types are ignored. How does that make sense then? Did I misunderstand that sentence? -David > On Aug 6, 2013, at 9:49 AM, David Lamparter wrote: > > 00 - ignore TLV > > this can be used for all "hint" TLVs, stuff like maybe communicating > > the origin ASN for external routes or whatever you can dream up. > > > > 01 - ignore parent > > on calculating SPF, completely ignore the resulting route. This is > > useful for MT-OSPF (if it ever happens), to be used on a MT-ID TLV > > with an MT-ID != 0. Basically, non-MT routers can ignore all nonzero > > MT topologies this way. > > > > 10 - strong unreachable > > mark the route's destination prefix as unreachable and install a > > corresponding blackhole/... route. This is the right thing to do on > > SADR routes when they hit a non-SADR router. Even if we have the same > > prefix reachable on a non-SADR route with a lower metric, we can't > > ensure that it's loop-free for a particular source address. > > > > 11 - weak unreachable (?) > > treat the route as "unreachable", adding it to the SPF result as such, > > if there is no shorter path to the same prefix so far. This is > > probably the least useful type, I can only come up with something like > > "route that requires special encapsulation (tunnel?)" - no idea on the > > reality here. From russw@riw.us Tue Aug 6 07:24:55 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 C6E8E21F8EE6 for ; Tue, 6 Aug 2013 07:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 iOkH4kpekHtV for ; Tue, 6 Aug 2013 07:24:50 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3A73921F8F2E for ; Tue, 6 Aug 2013 07:24:46 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1V6iBo-00059d-JF; Tue, 06 Aug 2013 07:24:44 -0700 From: "Russ White" To: "'David Lamparter'" , References: <20130806134954.GJ95257@jupiter.n2.diac24.net> In-Reply-To: <20130806134954.GJ95257@jupiter.n2.diac24.net> Date: Tue, 6 Aug 2013 10:24:48 -0400 Message-ID: <02c801ce92b0$b56f4230$204dc690$@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: AQKME5YFomzZRq60tI5aa5CJsaKHq5gNOgtw Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? 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, 06 Aug 2013 14:24:55 -0000 > looking at the Extended LSA draft from the various use cases, I believe it > would be advantageous to repurpose the topmost two bits of the TLV type > to indicate what should happen if the TLV is not supported by a router. I'm > thinking of 3-4 possible handlings: > > (these all only apply to parent TLVs or LSAs that specify a route in some way, > e.g. currently Inter/Intra/AS-Ext-Prefix LSAs. Though the first two make > sense in a generic way.) > > 00 - ignore TLV > this can be used for all "hint" TLVs, stuff like maybe communicating > the origin ASN for external routes or whatever you can dream up. > > 01 - ignore parent > on calculating SPF, completely ignore the resulting route. This is > useful for MT-OSPF (if it ever happens), to be used on a MT-ID TLV > with an MT-ID != 0. Basically, non-MT routers can ignore all nonzero > MT topologies this way. > > 10 - strong unreachable > mark the route's destination prefix as unreachable and install a > corresponding blackhole/... route. This is the right thing to do on > SADR routes when they hit a non-SADR router. Even if we have the same > prefix reachable on a non-SADR route with a lower metric, we can't > ensure that it's loop-free for a particular source address. These seem useful to me... > 11 - weak unreachable (?) > treat the route as "unreachable", adding it to the SPF result as such, > if there is no shorter path to the same prefix so far. This is > probably the least useful type, I can only come up with something like > "route that requires special encapsulation (tunnel?)" - no idea on the > reality here. This is really just max metric --I'm not certain we need another mechanism to achieve the same thing. :-) Russ From acee.lindem@ericsson.com Tue Aug 6 07:31: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 3CE9B21F9A13 for ; Tue, 6 Aug 2013 07:31:42 -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 CRmpcfTuXnVJ for ; Tue, 6 Aug 2013 07:31:35 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1DF21F9A34 for ; Tue, 6 Aug 2013 07:31:09 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-60-520108ac8292 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C8.64.13034.CA801025; Tue, 6 Aug 2013 16:31:08 +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; Tue, 6 Aug 2013 10:31:08 -0400 From: Acee Lindem To: David Lamparter Thread-Topic: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? Thread-Index: AQHOkqwAjkxiEC+2aEOyPevoodJ9h5mIfLUAgAABlICAAAKZgA== Date: Tue, 6 Aug 2013 14:31:07 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4702FEA3ED@eusaamb101.ericsson.se> References: <20130806134954.GJ95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA381@eusaamb101.ericsson.se> <20130806142149.GK95257@jupiter.n2.diac24.net> In-Reply-To: <20130806142149.GK95257@jupiter.n2.diac24.net> 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+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPrO4aDsYggxmb9C3WNG5gtmi5d4/d gcnjy14pjyVLfjIFMEVx2aSk5mSWpRbp2yVwZcz48YCt4DN/xdeJ09kaGA/zdDFyckgImEj8 2HSREcIWk7hwbz1bFyMXh5DAUUaJf4cWsEA4yxgl5r+/wARSxSagI/H80T9mEFtEQEOi7e0K oDgHB7OAqsTjo2wgYWGBGInuzZfYIUpiJaY0/WaFsJ0kZm3eBhZnEVCRWDLnOthiXgFfiY0P OsDGCwmsZ5SYcc8axOYUsJZ4fagBrJcR6Ljvp9aA1TALiEvcejKfCeJoAYkle84zQ9iiEi8f /2OFsJUlljzZzwJRryOxYPcnNgjbWuLW6+fsELa2xLKFr5khbhCUODnzCcsERvFZSFbMQtI+ C0n7LCTts5C0L2BkXcXIUVqcWpabbmSwiREYU8ck2HR3MO55aXmIUZqDRUmcd5XemUAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjMtU3TL5w12//zdq6tu9fbLg03MlM8rsLTezOzOUnL3o bDz54ynTlwVu6ZMaZE5KzKh7s6Yg5JiUg5/bnsmzl3pJW0XsnVbstznX81d/wALJ4raZzgeW fjGNlgg8lLpzo1S5xtsi4UWS52eVZ71kUZiy3qOeobJccbLc1ni9Xcd/bl+1QTxVU4mlOCPR UIu5qDgRAGiKpmp3AgAA Cc: "" Subject: Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? 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, 06 Aug 2013 14:31:42 -0000 On Aug 6, 2013, at 10:21 AM, David Lamparter wrote: > On Tue, Aug 06, 2013 at 02:16:10PM +0000, Acee Lindem wrote: >> I don't think this is a good idea at all. An implementation can only >> deal with the TLVs it understands so the ignore options don't make >> sense. >> If the other actions are necessary, we'd be better served with a more >> definitive use case and encoding than reusing TLV bits. >=20 > Section 3 of the draft states: > [...] Unrecognized types are ignored. > How does that make sense then? Did I misunderstand that sentence? No - the only valid option for a TLV that you don't recognize is to ignore = it. It makes no sense to attempt to imply some action based on bits in the = TLV type.=20 Acee=20 >=20 >=20 > -David >=20 >=20 >> On Aug 6, 2013, at 9:49 AM, David Lamparter wrote: >>> 00 - ignore TLV >>> this can be used for all "hint" TLVs, stuff like maybe communicating >>> the origin ASN for external routes or whatever you can dream up. >>>=20 >>> 01 - ignore parent >>> on calculating SPF, completely ignore the resulting route. This is >>> useful for MT-OSPF (if it ever happens), to be used on a MT-ID TLV >>> with an MT-ID !=3D 0. Basically, non-MT routers can ignore all nonzero >>> MT topologies this way. >>>=20 >>> 10 - strong unreachable >>> mark the route's destination prefix as unreachable and install a >>> corresponding blackhole/... route. This is the right thing to do on >>> SADR routes when they hit a non-SADR router. Even if we have the same >>> prefix reachable on a non-SADR route with a lower metric, we can't >>> ensure that it's loop-free for a particular source address. >>>=20 >>> 11 - weak unreachable (?) >>> treat the route as "unreachable", adding it to the SPF result as such, >>> if there is no shorter path to the same prefix so far. This is >>> probably the least useful type, I can only come up with something like >>> "route that requires special encapsulation (tunnel?)" - no idea on the >>> reality here. From equinox@diac24.net Tue Aug 6 07:41:55 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 A1A8321F992E for ; Tue, 6 Aug 2013 07:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, 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 VM8LFQRbEHyq for ; Tue, 6 Aug 2013 07:41:55 -0700 (PDT) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A06521F9DF1 for ; Tue, 6 Aug 2013 07:41:51 -0700 (PDT) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V6iSL-0000rZ-R4; Tue, 06 Aug 2013 16:41:50 +0200 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1V6iS9-0038eb-3v; Tue, 06 Aug 2013 16:41:39 +0200 Date: Tue, 6 Aug 2013 16:41:37 +0200 From: David Lamparter To: Acee Lindem Message-ID: <20130806144136.GM95257@jupiter.n2.diac24.net> References: <20130806134954.GJ95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA381@eusaamb101.ericsson.se> <20130806142149.GK95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA3ED@eusaamb101.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4702FEA3ED@eusaamb101.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "" Subject: Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? 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, 06 Aug 2013 14:41:55 -0000 On Tue, Aug 06, 2013 at 02:31:07PM +0000, Acee Lindem wrote: > On Aug 6, 2013, at 10:21 AM, David Lamparter wrote: > > On Tue, Aug 06, 2013 at 02:16:10PM +0000, Acee Lindem wrote: > >> I don't think this is a good idea at all. An implementation can only > >> deal with the TLVs it understands so the ignore options don't make > >> sense. > >> If the other actions are necessary, we'd be better served with a more > >> definitive use case and encoding than reusing TLV bits. > > > > Section 3 of the draft states: > > [...] Unrecognized types are ignored. > > How does that make sense then? Did I misunderstand that sentence? > > No - the only valid option for a TLV that you don't recognize is to > ignore it. It makes no sense to attempt to imply some action based on > bits in the TLV type. Hm. We have the same thing with U/S1/S2 bits in LSA function codes. Other protocols have a "critical" bit indicating ignore/error behaviour. I've tried to adapt that for a routing use case - I guess I'm not seeing the problem? Do you have a few minutes to explain in more depth? (I guess it needs a little more thinking in particular regarding multiple TLVs with different unsupported disposition, probably just an ordering and "choose worst". I've also implied without saying that all LSAs are flooded unmodified, i.e. U=1.) -David > >> On Aug 6, 2013, at 9:49 AM, David Lamparter wrote: > >>> 00 - ignore TLV > >>> this can be used for all "hint" TLVs, stuff like maybe communicating > >>> the origin ASN for external routes or whatever you can dream up. > >>> > >>> 01 - ignore parent > >>> on calculating SPF, completely ignore the resulting route. This is > >>> useful for MT-OSPF (if it ever happens), to be used on a MT-ID TLV > >>> with an MT-ID != 0. Basically, non-MT routers can ignore all nonzero > >>> MT topologies this way. > >>> > >>> 10 - strong unreachable > >>> mark the route's destination prefix as unreachable and install a > >>> corresponding blackhole/... route. This is the right thing to do on > >>> SADR routes when they hit a non-SADR router. Even if we have the same > >>> prefix reachable on a non-SADR route with a lower metric, we can't > >>> ensure that it's loop-free for a particular source address. > >>> > >>> 11 - weak unreachable (?) > >>> treat the route as "unreachable", adding it to the SPF result as such, > >>> if there is no shorter path to the same prefix so far. This is > >>> probably the least useful type, I can only come up with something like > >>> "route that requires special encapsulation (tunnel?)" - no idea on the > >>> reality here. > From acee.lindem@ericsson.com Tue Aug 6 07:49:40 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 3C94C21F84CD for ; Tue, 6 Aug 2013 07:49: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=[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 XanpUiGYUlqA for ; Tue, 6 Aug 2013 07:49:33 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D563021F9E7C for ; Tue, 6 Aug 2013 07:49:19 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-b3-52010ceec2f7 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3D.B5.13034.EEC01025; Tue, 6 Aug 2013 16:49:18 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 10:49:18 -0400 From: Acee Lindem To: David Lamparter Thread-Topic: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? Thread-Index: AQHOkqwAjkxiEC+2aEOyPevoodJ9h5mIfLUAgAABlICAAAKZgIAAAu+AgAACJAA= Date: Tue, 6 Aug 2013 14:49:17 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4702FEA4D2@eusaamb101.ericsson.se> References: <20130806134954.GJ95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA381@eusaamb101.ericsson.se> <20130806142149.GK95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA3ED@eusaamb101.ericsson.se> <20130806144136.GM95257@jupiter.n2.diac24.net> In-Reply-To: <20130806144136.GM95257@jupiter.n2.diac24.net> 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: <7EB52A2C32EF7641B79A51F5597C2246@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXRPlO47HsYgg12H9S3WNG5gtmi5d4/d gcnjy14pjyVLfjIFMEVx2aSk5mSWpRbp2yVwZfw52cpU8Eui4sf81ywNjC+Euxg5OSQETCQa Tr5lgrDFJC7cW8/WxcjFISRwlFHi28elzBDOMkaJaa+es4BUsQnoSDx/9I8ZxBYR0JBoe7sC qJuDg1lAVeLxUTaQsLBAjET35kvsECWxElOafrNC2H4SU6ccAFvGIqAicb5/GlgNr4CvxPP9 l6B2LWGS2L/uANh8TgFriVvXpoM1MAJd9/3UGjCbWUBc4taT+VBXC0gs2XOeGcIWlXj5+B8r hK0sseTJfhaIeh2JBbs/sUHY1hKtu9+yQ9jaEssWvmaGOEJQ4uTMJywTGMVnIVkxC0n7LCTt s5C0z0LSvoCRdRUjR2lxalluupHBJkZgVB2TYNPdwbjnpeUhRmkOFiVx3lV6ZwKFBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MHpyvtq+k7n1+/ZKmfnzav4YPuZM+8Sz/fVKNcnbjf/E9fdc iElf1cx5LDXHUP7UL/Mn525+XxMbevCr6nMli/fdC275SnScZCz1yW+8fHbX9vaFIQaXNp7V f/Ox5KDWbd+Yj6GssmwLfP/Vpt5uO37IbVZq07H8bd2NKSKaMund53Z9fV79mUWJpTgj0VCL uag4EQBuIMjQeAIAAA== Cc: "" Subject: Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? 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, 06 Aug 2013 14:49:40 -0000 On Aug 6, 2013, at 10:41 AM, David Lamparter wrote: > On Tue, Aug 06, 2013 at 02:31:07PM +0000, Acee Lindem wrote: >> On Aug 6, 2013, at 10:21 AM, David Lamparter wrote: >>> On Tue, Aug 06, 2013 at 02:16:10PM +0000, Acee Lindem wrote: >>>> I don't think this is a good idea at all. An implementation can only >>>> deal with the TLVs it understands so the ignore options don't make >>>> sense. >>>> If the other actions are necessary, we'd be better served with a more >>>> definitive use case and encoding than reusing TLV bits. >>>=20 >>> Section 3 of the draft states: >>> [...] Unrecognized types are ignored. >>> How does that make sense then? Did I misunderstand that sentence? >>=20 >> No - the only valid option for a TLV that you don't recognize is to >> ignore it. It makes no sense to attempt to imply some action based on >> bits in the TLV type. >=20 > Hm. We have the same thing with U/S1/S2 bits in LSA function codes. > Other protocols have a "critical" bit indicating ignore/error behaviour. > I've tried to adapt that for a routing use case - I guess I'm not seeing > the problem? Do you have a few minutes to explain in more depth? These bits are for flooding behavior of the LSA (a generic OSPFv3 operation= ) independent of the LSA purpose or context. This is opposed to attempting = to define SPF specific behavior for TLVs that may or may not contain SPF sp= ecific information.=20 >=20 > (I guess it needs a little more thinking in particular regarding > multiple TLVs with different unsupported disposition, probably just an > ordering and "choose worst". I've also implied without saying that all > LSAs are flooded unmodified, i.e. U=3D1.) No - this draft will NOT include modifying LSAs. This is a slippery slope a= nd one best not even considered.=20 Acee=20 >=20 >=20 > -David >=20 >>>> On Aug 6, 2013, at 9:49 AM, David Lamparter wrote: >>>>> 00 - ignore TLV >>>>> this can be used for all "hint" TLVs, stuff like maybe communicating >>>>> the origin ASN for external routes or whatever you can dream up. >>>>>=20 >>>>> 01 - ignore parent >>>>> on calculating SPF, completely ignore the resulting route. This is >>>>> useful for MT-OSPF (if it ever happens), to be used on a MT-ID TLV >>>>> with an MT-ID !=3D 0. Basically, non-MT routers can ignore all nonze= ro >>>>> MT topologies this way. >>>>>=20 >>>>> 10 - strong unreachable >>>>> mark the route's destination prefix as unreachable and install a >>>>> corresponding blackhole/... route. This is the right thing to do on >>>>> SADR routes when they hit a non-SADR router. Even if we have the sam= e >>>>> prefix reachable on a non-SADR route with a lower metric, we can't >>>>> ensure that it's loop-free for a particular source address. >>>>>=20 >>>>> 11 - weak unreachable (?) >>>>> treat the route as "unreachable", adding it to the SPF result as such= , >>>>> if there is no shorter path to the same prefix so far. This is >>>>> probably the least useful type, I can only come up with something lik= e >>>>> "route that requires special encapsulation (tunnel?)" - no idea on th= e >>>>> reality here. >>=20 From russw@riw.us Tue Aug 6 08:41: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 9603121F9476 for ; Tue, 6 Aug 2013 08:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 YoaImffOwsLn for ; Tue, 6 Aug 2013 08:41:14 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 29E4C21F9B57 for ; Tue, 6 Aug 2013 08:41:09 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1V6jNf-0001aX-AG; Tue, 06 Aug 2013 08:41:03 -0700 From: "Russ White" To: "'Acee Lindem'" , "'David Lamparter'" References: <20130806134954.GJ95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA381@eusaamb101.ericsson.se> <20130806142149.GK95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA3ED@eusaamb101.ericsson.se> <20130806144136.GM95257@jupiter.n2.diac24.net> <94A203EA12AECE4BA92D42DBFFE0AE4702FEA4D2@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4702FEA4D2@eusaamb101.ericsson.se> Date: Tue, 6 Aug 2013 11:41:07 -0400 Message-ID: <038101ce92bb$5e8e8060$1bab8120$@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: AQKME5YFomzZRq60tI5aa5CJsaKHqwHi2JGCAirYwvQBpgThigJYgvJnAlFw81aXumAZkA== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: ospf@ietf.org Subject: Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? 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, 06 Aug 2013 15:41:20 -0000 > These bits are for flooding behavior of the LSA (a generic OSPFv3 operation) > independent of the LSA purpose or context. This is opposed to attempting to > define SPF specific behavior for TLVs that may or may not contain SPF specific > information. I think the problem here might be one of wording, rather than intent --the way David worded his original email was, "let's put bits in to tell a receiving router how to handle an LSA it doesn't understand." Acee's response is, essentially, "if you don't know how to handle it, then how are these bits going to matter? The only valid response to an LSA you don't understand is to drop it." I think David's idea should be rephrased to something like this: "Is it useful to have bits that will instruct a router to process any given LSA in a specific way, rather than leaving it up to the receiver to determine all possible cases independently?" In other words, LSAs are transmitted with the "intent," that the information in the LSA be used to build the SPT, and hence to install routes in the local routing table. But there may be instances where the originator doesn't actually want the route included in the SPT, nor the local routing table. The key is to see if there actually any valid cases where this is true or not. If not, then we can safely ignore the entire idea (at least for now). If there are valid use cases, then... So let's look at the use cases a bit (?): > 01 - ignore parent > on calculating SPF, completely ignore the resulting route. This > is useful for MT-OSPF (if it ever happens), to be used on a MT-ID > TLV with an MT-ID != 0. Basically, non-MT routers can ignore all > nonzero MT topologies this way. I guess this might also be solved by an MT router simply ignoring any MT information around topologies it's not locally calculating for, correct? Is there a need for an explicit notification of what to do with information about topologies you're not routing for? > 10 - strong unreachable > mark the route's destination prefix as unreachable and install a > corresponding blackhole/... route. This is the right thing to do > on SADR routes when they hit a non-SADR router. Even if we have > the same prefix reachable on a non-SADR route with a lower metric, > we can't ensure that it's loop-free for a particular source address. I think this is useful, but it's more of a security thing than a routing thing directly. I don't know if the WG would agree that this is something that could/should be carried in OSPF, nor have I spent a lot of time thinking about how it would actually be included in the SPT. Russ From prz@mail.zeta2.ch Tue Aug 6 09:11: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 0B33221F9AA1 for ; Tue, 6 Aug 2013 09:11:43 -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 Gm5HnlboF4dD for ; Tue, 6 Aug 2013 09:11:38 -0700 (PDT) Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id 5192121F9998 for ; Tue, 6 Aug 2013 09:11:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r76GBZpO006621 for ; Tue, 6 Aug 2013 18:11:35 +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 TBmjopFAAb7W for ; Tue, 6 Aug 2013 18:11:30 +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 r76GBPJD006419 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 6 Aug 2013 18:11:29 +0200 Message-ID: <5201202D.1020907@zeta2.ch> Date: Tue, 06 Aug 2013 18:11:25 +0200 From: "A. Przygienda" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: ospf@ietf.org References: <20130806134954.GJ95257@jupiter.n2.diac24.net> In-Reply-To: <20130806134954.GJ95257@jupiter.n2.diac24.net> Content-Type: multipart/mixed; boundary="------------060506040805030807000505" Subject: Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? 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, 06 Aug 2013 16:11:43 -0000 This is a multi-part message in MIME format. --------------060506040805030807000505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/06/2013 03:49 PM, David Lamparter wrote: > Hi ospf WG, > > > looking at the Extended LSA draft from the various use cases, I believe > it would be advantageous to repurpose the topmost two bits of the TLV > type to indicate what should happen if the TLV is not supported by a > router. I'm thinking of 3-4 possible handlings: > ... > > > -David > an impressively deep rathole. Games like that CAN be played (actually, that's why things like MT-ISIS was possible at all) _BUT_ a closed proof is needed that ignoring certain LSAs by certain routers will _NOT_ lead to routing loops (in hop-by-hop routing) since routers hold now for their SPFs different LSDBs. The theory (yes, it's not light bedtime reading) can be found in http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=749255&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel4%2F6063%2F16198%2F00749255.pdf%3Farnumber%3D749255 and that should also enlighten why the concept of 'topology' as in mathematical 'topology' plays such a strong role. I would simplify here however & double Russ's suggestion on wanting a use-case for the goodies proposed first --- tony --------------060506040805030807000505 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 --------------060506040805030807000505-- From ppsenak@cisco.com Tue Aug 6 11:45: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 44A7711E80FC for ; Tue, 6 Aug 2013 11:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 Bd8viGHzj3KO for ; Tue, 6 Aug 2013 11:45:18 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D910621F997D for ; Tue, 6 Aug 2013 11:45:15 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r76IjDtb017589 for ; Tue, 6 Aug 2013 20:45:13 +0200 (CEST) Received: from [10.55.51.199] (ams-ppsenak-8716.cisco.com [10.55.51.199]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r76Ij9qo022817; Tue, 6 Aug 2013 20:45:10 +0200 (CEST) Message-ID: <52014435.5030905@cisco.com> Date: Tue, 06 Aug 2013 20:45:09 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Lamparter References: <20130806134954.GJ95257@jupiter.n2.diac24.net> In-Reply-To: <20130806134954.GJ95257@jupiter.n2.diac24.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"? 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, 06 Aug 2013 18:45:22 -0000 David, 00 - ignoring unrecognized TVLs is a standard thing to do 01 - non-MT routers would ignore all TLVs related to MT-ID other then 0 anyway, there is nothing special you need to do. If the non-MT capable router tries to do anything with TLV which is bound to a non-0 MT, or interpret any data that relates to non-0 MT, its a bug on that router. 10 - you can achieve this by advertising the SADR capability in the RI LSA and do it for any prefix coming from the non-SADR router, no per TLV granularity is required. 11 - looks like a router STUB advertisement BTW, we should set the U-bit on all Extended LSAs and I believe Acee has agreed on that already. thanks, Peter On 8/6/13 15:49 , David Lamparter wrote: > Hi ospf WG, > > > looking at the Extended LSA draft from the various use cases, I believe > it would be advantageous to repurpose the topmost two bits of the TLV > type to indicate what should happen if the TLV is not supported by a > router. I'm thinking of 3-4 possible handlings: > > (these all only apply to parent TLVs or LSAs that specify a route in > some way, e.g. currently Inter/Intra/AS-Ext-Prefix LSAs. Though the > first two make sense in a generic way.) > > 00 - ignore TLV > this can be used for all "hint" TLVs, stuff like maybe communicating > the origin ASN for external routes or whatever you can dream up. > > 01 - ignore parent > on calculating SPF, completely ignore the resulting route. This is > useful for MT-OSPF (if it ever happens), to be used on a MT-ID TLV > with an MT-ID != 0. Basically, non-MT routers can ignore all nonzero > MT topologies this way. > > 10 - strong unreachable > mark the route's destination prefix as unreachable and install a > corresponding blackhole/... route. This is the right thing to do on > SADR routes when they hit a non-SADR router. Even if we have the same > prefix reachable on a non-SADR route with a lower metric, we can't > ensure that it's loop-free for a particular source address. > > 11 - weak unreachable (?) > treat the route as "unreachable", adding it to the SPF result as such, > if there is no shorter path to the same prefix so far. This is > probably the least useful type, I can only come up with something like > "route that requires special encapsulation (tunnel?)" - no idea on the > reality here. > > Note that this is supposed to work in conjunction with other ways of > communicating per-router capabilities, e.g. Router Information LSAs. > A router may well need to take a different action when, on calculating, > it notices that it passed by a router without support for feature XYZ. > Since that applies to routers that *do* implement a particular > extension, the exact behaviour for this needs to be specified in that > extension. > > Comments? > > > -David > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > From yiya@cisco.com Thu Aug 8 18:37: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 E1D1D11E817D for ; Thu, 8 Aug 2013 18:37: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 c-o1MVUy7bXC for ; Thu, 8 Aug 2013 18:37:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC0111E80F8 for ; Thu, 8 Aug 2013 18:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5064; q=dns/txt; s=iport; t=1376012237; x=1377221837; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UFwFR0GoixfPl9f+ivZkmif6i+jU397tnQww5Yt9m+4=; b=TQPjcxmw4uiPBWXj/J7MvwCuQriyiGox45las9d78ELaOrjeJxHKW8fB GiCDoEA1GvyAZ2LiH5jnM+kBwEPi/iB4QaqD736NuUtSr+e2/2W5x/4X7 UF4FI2o4U4XNOaFnvTyLiqHaoNUloxL99C9JWDhxSXwI8NF9lBNFZtrZ7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAFFHBFKtJXHB/2dsb2JhbABbgwY1UKwmkiiBGRZ0giQBAQEEAQEBNzICCxIBCA4DBAEBAQoUMQYLEwoIAgQBDQUIh3YDDwyvdA2IXo0rgj8xB4MadAOVeASCG3SKfoUngV+BOYIq X-IronPort-AV: E=Sophos;i="4.89,843,1367971200"; d="scan'208";a="245281192" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 09 Aug 2013 01:37:16 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r791bGe7008210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 01:37:16 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.144]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 8 Aug 2013 20:37:15 -0500 From: "Yi Yang (yiya)" To: Gabi Nakibly , Acee Lindem , David Lamparter , Glen Kent Thread-Topic: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) Thread-Index: AQHOlKD6hb+nS+9dYkaGPDIp2FKfDw== Date: Fri, 9 Aug 2013 01:37:15 +0000 Message-ID: In-Reply-To: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> 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: [10.116.75.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <909950D36C72734AA44F5C9DFB29B670@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Fri, 09 Aug 2013 01:37:22 -0000 I would think such an attack can be categorized as "overclaiming", as defined at http://tools.ietf.org/html/rfc4593#section-4.5.1.1. In this case, an attacker claims a resource (link state ID) which does not belong to it.=20 While it might be challenging to defense overclaiming in some cases, it's not that hard to recognize the attack in this case. As pointed out by David and Acee, such LSAs should be considered as malformatted as they have unmatched Advertising Router and Link State ID and can be dropped. A more challenging example of overclaiming is the attacker simply advertises a bunch of prefixes that are not really attached on itself. Yi=20 =20 On 8/5/13 5:03 PM, "Gabi Nakibly" wrote: >Hi all, >My name is Gabi. I am the researcher who presented the new attack at >Black Hat last week. I have noticed the discussion on the list and I >would be happy to try to clarify how the attack is different from known >ones.=20 >Indeed the attack assumes that the attacker is an insider, meaning that >the attacker has already gained control of one of the router within the >AS. I agree 100% that once an attacker is an insider he can already do >all sorts of attacks that can harm the network and indeed a few past >works have already reported on this. Nonetheless, the crux of the new >attack, as Acee has already pointed out, is that an attacker is now able >to falsify an LSA on behalf of another router while evading the >fight-back mechanism. This new capability allows an attacker to >*persistently* and *stealthily* subvert the LSA DB of other routers that >install the false LSA and thereby altering their routing tables. This >gives rise to a new class of attacks that in my opinion have not existed >before and, in many times, are more desirable for an attacker (due to >their stealth and persistence). >To my best knowledge, no other general technique to stealthily evade >fight back is known. The only general attack technique to evade fight >back is periodic injection (flooding false LSAs at a rate higher thanone >every MinLSInterval) presented in >http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.txt in Section >4.1.3.1. However, using such technique the attack is hardly stealthy. > >BTW, I have also presented in the past another general technique to evade >fight back called 'Disguised LSA'. It is described in >https://www.cs.technion.ac.il/people/gnakibly/online-publications/Persiste >ntOSPF.pdf in Section 4.2. > >I would appreciate your continued feedback on the new attack. > >Thanks, >Gabi > >>________________________________ >> From: Acee Lindem >>To: David Lamparter ; Glen Kent >> >>Cc: "ospf@ietf.org" >>Sent: Monday, August 5, 2013 5:28 AM >>Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the >>Routing Table Attack) >>=20 >> >> >> >>On 8/4/13 6:06 AM, "David Lamparter" wrote: >> >>>On Fri, Aug 02, 2013 at 10:11:01PM +0530, Glen Kent wrote: >>>> Does anybody have details on what this OSPF vulnerability is? >>>>=20 >>>> https://www.blackhat.com/us-13/briefings.html#Nakibly >>> >>>As people may have noticed by now (the embargo on 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. As such, this >>>attack is implementable from any router in an OSPF area against any >>>other router in the OSPF. >>> >>>(Quite honestly, IMHO this is seriously far fetched. If your control >>>plane got compromised this far you have other problems.) >> >>I agree that once the OSPF control plane is open, you are susceptible to >>many attacks. However, this attack is a bit more insidious than most >>since >>the actual OSPF router corresponding to the link state ID will most >>likely >>not recognize the LSA as self-originated and re-originate a more recent >>version when the 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. >> >>> >>>While Quagga is unaffected by this, we've implemented a warning. We're >>>also considering dropping the LSA outright, but I'm somewhat split on >>>that (tilted towards dropping). I'd be interested if the WG has >>>comments on that? >> >>I can't speak for the WG but my implementation will skip the LSA in the >>Link-State Update packet. >> >>Thanks, >>Acee >> >> >>> >>> >>>-David >>>_______________________________________________ >>>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 From acee@lindem.com Sat Aug 10 16:14: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 01D5F11E80D2 for ; Sat, 10 Aug 2013 16:14: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] 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 ldcpNGWHhO00 for ; Sat, 10 Aug 2013 16:14:07 -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 E728C21F9223 for ; Sat, 10 Aug 2013 16:06:49 -0700 (PDT) X-Authority-Analysis: v=2.0 cv=TPPHuiZa c=1 sm=0 a=C2g1Hp6idNFTy4K9KrF8yg==:17 a=x7FEv9pE1mkA:10 a=vErhmaPM-wEA:10 a=Wma4Of2gTTwA:10 a=kj9zAlcOel0A:10 a=QYaTxUjTAAAA:8 a=KGjhK52YXX0A:10 a=ybZnzFyYZQMA:10 a=48vgC7mUAAAA:8 a=VJ3LcXVN-qw1gMotBdkA:9 a=CjuIK1q_8ugA: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:64116] helo=[192.168.1.106]) by cdptpa-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id B5/09-14128-887C6025; Sat, 10 Aug 2013 23:06:49 +0000 From: Acee Lindem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 10 Aug 2013 19:06:47 -0400 Message-Id: <644A5B64-94D0-4A2E-9076-6593DB1F7C1F@lindem.com> To: OSPF List Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Cc: Sean Turner Subject: [OSPF] RFC6506 Bis Draft as OSPF WG Document 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, 10 Aug 2013 23:14:12 -0000 Due to a couple errata on RFC 6506, I made the decision to respin the = RFC in an effort to ensure compatibility between implementations and as = a service to the OSPF community. At IETF 87, discussions with our AD and = polling at the WG meeting indicating support of making this a WG = document.=20 At this time, I'd like to ask if anyone is opposed to making this a WG = document? The intent would be to move swiftly to WG last call.=20 For your convenience, here is the URL: = http://www.ietf.org/id/draft-acee-ospf-rfc6506bis-03.txt Thanks, Acee=20= From gnakibly@yahoo.com Sun Aug 11 12:30: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 D310211E80DF for ; Sun, 11 Aug 2013 12:30:01 -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_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 Nvu4e1FpvlDS for ; Sun, 11 Aug 2013 12:29:57 -0700 (PDT) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 7A80111E80E0 for ; Sun, 11 Aug 2013 12:22:42 -0700 (PDT) Received: from [98.139.212.151] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 11 Aug 2013 19:22:41 -0000 Received: from [98.139.212.207] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 11 Aug 2013 19:22:41 -0000 Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 11 Aug 2013 19:22:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 632606.29750.bm@omp1016.mail.bf1.yahoo.com Received: (qmail 55227 invoked by uid 60001); 11 Aug 2013 19:22:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1376248961; bh=8x7wuk+vSj74YQTyIeU4byCPPmU/zHxibCY4itLgiGM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mmCrGdq13bTryvb4doWqZd7BPu1M4fhVHlxmSE/3RUHoZjvyz7I8MmEOkGOB7jVjWvNyP6PvbcE5tvka5EqNMFl1uZnyoF/s5FTTyYfU3kuahbc40zcTevo2rf0gxJJ+ih23InPq8cz8hvnK/T9FFKrqcu710oZGMqq2efhbgdQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cOkwEBc6gfQ0qIMXlsxhS34L2dJlrqUPq2jJ37BKdN8AG4ue0xjISeISxyPIc3eZDRmmLbAmTXlm5a4u9B9mjuH8C3xPONhzBea/8JRTb/JQYgpa7xJdr+TZwVldUuJoVsVImpLLZCto6UBhELuh+m3QVBtf72A9S7CQkBtof7o=; X-YMail-OSG: 7Omvv2gVM1n.LF4VwaqA2mrldbzem8o3GPkH9EbvbgRWUFe DJTl5fy2IElkIPgZT47XnRel3xWSpkhe1p6dktOJThJqipJ.C5ngPLduhu_T q8u0EAPRchkJ8xvFPJfjPtCSH9U9O0pUsV53Tql.ujrFg6p6zXP1QnumT7FB W2oUcbABr3JcWcB0uhuDMF72wRaXRmswMlFvIWO3Kv5I8.qEWoey5ogh0ai2 xh0kMi80wnjt3zz_ZOBPgAWBkyOcH8OcX2EdxCxQg1gdn055eg_GXg0PKzMi xPkQNvFeL_lVedLMpJcZ1ypH8lP1rYpbYsdOFCv9Z_jDWcIAm.ve8vYxiQO8 ntBzgbFr73Dohl0n.s7Hp847NjXc9q3rVaTC6nB9q5R_IHgnarosmRT9C5zM YWzrku7lBdnmTq5om1.s0AAZvAgeVK1O8LH4oy4D4h9UEOkQ1j9ZCF0anFvL q9pc1d.MFjEo.0SmSrgbNExWp4pJYRp4h3nGpa5_Jwd4juEEy1I7jXuGenWr whIgq_JU9crBzkrZpv0uuF5vnTWbBNOKgoA0isnSGQcqzkn5U09aABsu263t hMVdVPXQsjh_mexBxZeFlu8x2DluPpCUD9yoQpipRnUz3OqG0GPi0lU2Ul8_ bHoL3HvdGLaCf6cjnXWITSpGynpVtZtfCCSGEq1w301I_aSqw2_hqh7fh2tZ q5.A54SjYaayv8H6DLJlANSsYHA0_MRbZNq2K3DMPXhfVsnGsVK2TME6YVTj RvaXhs2wkTzgUUKlhZ2e7kVYul4Ttk3vpxdh75NTJw.d0O7.0 Received: from [85.64.247.76] by web165004.mail.bf1.yahoo.com via HTTP; Sun, 11 Aug 2013 12:22:41 PDT X-Rocket-MIMEInfo: 002.001, SGkgWWksCkluZGVlZCwgbWl0aWdhdGluZyB0aGUgYXR0YWNrIGNhbm5vdCBiZSBlYXNpZXIsIGlmIHlvdSBsb29rIGZvciB0aGUgcmlnaHQgbWFsZm9ybWVkIHBhY2tldC4gWW91IG9ubHkgbmVlZCB0byBjaGVjayB0aGF0IHRoZSBMaW5rIFN0YXRlIElEIGVxdWFscyB0aGUgQWR2ZXJ0aXNpbmcgUm91dGVyLiBUaGlzIG1lYXN1cmUgaXMgbm93IGVtcGxveWVkIGJ5IENpc2NvLCBKdW5pcGVyIGFuZCBhIGZldyBvdGhlciB2ZW5kb3JzLiBOb25ldGhlbGVzcywgSSBhbSBzdXJlIHRoYXQgdGhlcmUgYXJlIG1vcmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.153.572 References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> Message-ID: <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> Date: Sun, 11 Aug 2013 12:22:41 -0700 (PDT) From: Gabi Nakibly To: "Yi Yang \(yiya\)" , Acee Lindem , David Lamparter , Glen Kent In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 Reply-To: Gabi Nakibly List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 19:30:02 -0000 Hi Yi,=0AIndeed, mitigating the attack cannot be easier, if you look for th= e right malformed packet. You only need to check that the Link State ID equ= als the Advertising Router. This measure is now employed by Cisco, Juniper = and a few other vendors. Nonetheless, I am sure that there are more OSPF ve= ndors out there that are still vulnerable to the attack and do not check fo= r this. Moreover, since this check is not part of the standard, in most lik= elihood future OSPF implementations will also be vulnerable.=0A=0AAs RFC 45= 93 points out, byzantine attacks are possible form of attack against routin= g protocols and measures should be employed=A0 to "minimize the impact of a= ttacks of this sort". IMHO, since byzantine attacks do occur in practice an= d the mitigation for this specific attack is easy to deploy, the WG might w= ant to do an effort to advice on the mitigation measures for this attack.= =0A=0AI am willing to write a draft describing this mitigation measure. I w= ould appreciate the list's thoughts on this.=0A=0AGabi=0A=0A----- Original = Message -----=0A> From: Yi Yang (yiya) =0A> To: Gabi Nakibl= y ; Acee Lindem ; David Lampa= rter ; Glen Kent =0A> Cc: "ospf@ie= tf.org" =0A> Sent: Friday, August 9, 2013 4:37 AM=0A> Subjec= t: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table= Attack)=0A> =0A> I would think such an attack can be categorized as "overc= laiming", as=0A> defined at http://tools.ietf.org/html/rfc4593#section-4.5.= 1.1. In this=0A> case, an attacker claims a resource (link state ID) which = does not belong=0A> to it. =0A> =0A> While it might be challenging to defen= se overclaiming in some cases, it's=0A> not that hard to recognize the atta= ck in this case. As pointed out by=0A> David and Acee, such LSAs should be = considered as malformatted as they=0A> have unmatched Advertising Router an= d Link State ID and can be dropped. A=0A> more challenging example of overc= laiming is the attacker simply advertises=0A> a bunch of prefixes that are = not really attached on itself.=0A> =0A> Yi =0A> =A0 =0A> =0A> On 8/5/13 5:0= 3 PM, "Gabi Nakibly" wrote:=0A> =0A>> Hi all,=0A>> My = name is Gabi. I am the researcher who presented the new attack at=0A>> Blac= k Hat last week. I have noticed the discussion on the list and I=0A>> would= be happy to try to clarify how the attack is different from known=0A>> one= s. =0A>> Indeed the attack assumes that the attacker is an insider, meaning= that=0A>> the attacker has already gained control of one of the router wit= hin the=0A>> AS. I agree 100% that once an attacker is an insider he can al= ready do=0A>> all sorts of attacks that can harm the network and indeed a f= ew past=0A>> works have already reported on this. Nonetheless,=A0 the crux = of the new=0A>> attack, as Acee has already pointed out, is that an attacke= r is now able=0A>> to falsify an LSA on behalf of another router while evad= ing the=0A>> fight-back mechanism. This new capability allows an attacker t= o=0A>> *persistently* and *stealthily* subvert the LSA DB of other routers = that=0A>> install the false LSA and thereby altering their routing tables. = This=0A>> gives rise to a new class of attacks that in my opinion have not = existed=0A>> before and, in many times, are more desirable for an attacker = (due to=0A>> their stealth and persistence).=0A>> To my best knowledge, no = other general technique to stealthily evade=0A>> fight back is known. The o= nly general attack technique to evade fight=0A>> back is periodic injection= (flooding false LSAs at a rate higher thanone=0A>> every MinLSInterval)=A0= presented in=0A>> http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.t= xt in Section=0A>> 4.1.3.1. However,=A0 using such technique the attack is = hardly stealthy.=0A>> =0A>> BTW, I have also presented in the past another = general technique to evade=0A>> fight back called 'Disguised LSA'. It is de= scribed in=0A>> https://www.cs.technion.ac.il/people/gnakibly/online-public= ations/Persiste=0A>> ntOSPF.pdf in Section 4.2.=0A>> =0A>> I would apprecia= te your continued feedback on the new attack.=0A>> =0A>> Thanks,=0A>> Gabi= =0A>> =0A>>> ________________________________=0A>>>=A0=A0From: Acee Lindem = =0A>>> To: David Lamparter ; = Glen Kent=0A>>> =0A>>> Cc: "ospf@ietf.org" =0A>>> Sent: Monday, August 5, 2013 5:28 AM=0A>>> Subject: Re: [OSPF] D= ropping malformed LSAs (was: OSPF - Owning the=0A>>> Routing Table Attack)= =0A>>> =0A>>> =0A>>> =0A>>> =0A>>> On 8/4/13 6:06 AM, "David Lamparter" =0A= > wrote:=0A>>> =0A>>>> On Fri, Aug 02, 2013 at 10:11:0= 1PM +0530, Glen Kent wrote:=0A>>>>>=A0=A0Does anybody have details on what = this OSPF vulnerability is?=0A>>>>> =0A>>>>>=A0=A0https://www.blackhat.com/= us-13/briefings.html#Nakibly=0A>>>> =0A>>>> As people may have noticed by n= ow (the embargo on providing details =0A> has=0A>>>> expired as the talk wa= s presented), this issue consists of Router =0A> LSAs=0A>>>> where the Rout= er ID is different from the Link State ID.=A0 As such, =0A> this=0A>>>> att= ack is implementable from any router in an OSPF area against any=0A>>>> oth= er router in the OSPF.=0A>>>> =0A>>>> (Quite honestly, IMHO this is serious= ly far fetched.=A0 If your =0A> control=0A>>>> plane got compromised this f= ar you have other problems.)=0A>>> =0A>>> I agree that once the OSPF contro= l plane is open, you are susceptible to=0A>>> many attacks. However, this a= ttack is a bit more insidious than most=0A>>> since=0A>>> the actual OSPF r= outer corresponding to the link state ID will most=0A>>> likely=0A>>> not r= ecognize the LSA as self-originated and re-originate a more recent=0A>>> ve= rsion when the malformed one is received. Hence, the malicious LSA =0A> wil= l=0A>>> remain in the routing domain and, depending upon the OSPF =0A> impl= ementation,=0A>>> could result in traffic being redirected.=0A>>> =0A>>>> = =0A>>>> While Quagga is unaffected by this, we've implemented a =0A> warnin= g.=A0 We're=0A>>>> also considering dropping the LSA outright, but I'm some= what =0A> split on=0A>>>> that (tilted towards dropping).=A0 I'd be interes= ted if the WG has=0A>>>> comments on that?=0A>>> =0A>>> I can't speak for t= he WG but my implementation will skip the LSA in =0A> the=0A>>> Link-State = Update packet.=0A>>> =0A>>> Thanks,=0A>>> Acee=0A>>> =0A>>> =0A>>>> =0A>>>>= =0A>>>> -David=0A>>>> _______________________________________________=0A>>= >> OSPF mailing list=0A>>>> OSPF@ietf.org=0A>>>> https://www.ietf.org/mailm= an/listinfo/ospf=0A>>> =0A>>> _____________________________________________= __=0A>>> OSPF mailing list=0A>>> OSPF@ietf.org=0A>>> https://www.ietf.org/m= ailman/listinfo/ospf=0A>>> =0A>>> =0A>>> =0A>> ____________________________= ___________________=0A>> OSPF mailing list=0A>> OSPF@ietf.org=0A>> https://= www.ietf.org/mailman/listinfo/ospf=0A> From acee.lindem@ericsson.com Tue Aug 13 09:46: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 8616911E8191 for ; Tue, 13 Aug 2013 09:46:02 -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 m2MFOUP-SdrN for ; Tue, 13 Aug 2013 09:45:57 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 00C7311E810B for ; Tue, 13 Aug 2013 09:45:56 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-34-520a62bdefdc Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C9.FA.31362.EB26A025; Tue, 13 Aug 2013 18:45:50 +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; Tue, 13 Aug 2013 12:45:49 -0400 From: Acee Lindem To: OSPF List Thread-Topic: New Version Notification for draft-ietf-ospf-rfc6506bis-00.txt Thread-Index: AQHOmD9DwaDiAsAOA0OEVW6iRqaD9Q== Date: Tue, 13 Aug 2013 16:45:49 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030127F1@eusaamb101.ericsson.se> References: <20130813160723.26407.67738.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: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47030127F1eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyuXRPoO6+JK4gg5YnIhYt9+6xOzB6LFny kymAMYrLJiU1J7MstUjfLoEr40lvZMFk64rN58wbGD8YdzFyckgImEhMWvmXGcIWk7hwbz1b FyMXh5DAUUaJR1P/sUA4yxklbh54yw5SxSagI/H80T+wDhEBWYmlS/azgtjCAj4Sdxe8hIr7 SPSsugNUzwFk60ncuaAHEmYRUJVonfcDLMwr4CvR8b0EJCwk4Chx4NczJhCbEeiG76fWgNnM AuISt57MZ4K4TUBiyZ7zUHeKSrx8/I8VwlaWWPJkPwtEfb7EqXOnwK7kFRCUODnzCcsERuFZ SEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceQ/VaS7xdeosFWc0CRo5VjBylxalluelG hpsYgTFyTILNcQfjgk+WhxilOViUxHk36J0JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDo +O9u5FLhRrXyz+uuBh+ZHvu5Rq5iuoKKil9a56JL3s+XeiT4f/13VOjyBKWEF4/8dSPdPrnV 9mjNCfweV+w0letx44Pl6dcOKnPtkUxmn9PLKJ5VUZL68YykeTzD1Xhb1sbJ6W6zeIqn3t5o Z/54/iIH9wXa3lPe+szSOPIn7e+0SSLyj7OVWIozEg21mIuKEwHKqGe/XwIAAA== Subject: [OSPF] Fwd: New Version Notification for draft-ietf-ospf-rfc6506bis-00.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, 13 Aug 2013 16:46:02 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47030127F1eusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This draft addresses key RFC 6506 errata and adds clarifications where ther= e was ambiguity. We plan to WG last call shortly. RFC 6506 implementors - please review and either assure this is the version= that you follow or raise an issue. Thanks, Acee Begin forwarded message: From: > Date: August 13, 2013 12:07:23 PM EDT To: Manav Bhatia >, Vishwas Manral >, Acee Lindem > Subject: New Version Notification for draft-ietf-ospf-rfc6506bis-00.txt A new version of I-D, draft-ietf-ospf-rfc6506bis-00.txt has been successfully submitted by Manav Bhatia and posted to the IETF repository. Filename: draft-ietf-ospf-rfc6506bis Revision: 00 Title: Supporting Authentication Trailer for OSPFv3 Creation date: 2013-08-13 Group: ospf Number of pages: 26 URL: http://www.ietf.org/internet-drafts/draft-ietf-ospf-rfc650= 6bis-00.txt Status: http://datatracker.ietf.org/doc/draft-ietf-ospf-rfc6506bis Htmlized: http://tools.ietf.org/html/draft-ietf-ospf-rfc6506bis-00 Abstract: Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. This document obsoletes RFC 6506. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_94A203EA12AECE4BA92D42DBFFE0AE47030127F1eusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <70F067F3A458A445AA83EF7014870486@ericsson.com> Content-Transfer-Encoding: quoted-printable This draft addresses key RFC 6506 errata and adds clarifications where ther= e was ambiguity. We plan to WG last call shortly. 

RFC 6506 implementors - please review and either assure this is = the version that you follow or raise an issue.

Thanks,
Acee
Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Date: Augus= t 13, 2013 12:07:23 PM EDT
To: Manav= Bhatia <manav.bhatia= @alcatel-lucent.com>, Vishwas Manral <vishwas.manral@hp.com>, Acee Lindem <acee.lindem@ericsso= n.com>
Subject: Ne= w Version Notification for draft-ietf-ospf-rfc6506bis-00.txt


A new version of I-D, draft-ietf-ospf-rfc6506bis-00.txt
has been successfully submitted by Manav Bhatia and posted to the
IETF repository.

Filename: d= raft-ietf-ospf-rfc6506bis
Revision: 0= 0
Title: Supporting Auth= entication Trailer for OSPFv3
Creation date: 2013-08-13
Group: ospf
Number of pages: 26
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-ietf-ospf-rfc6506bis-00.= txt
Status:          http://datatracke= r.ietf.org/doc/draft-ietf-ospf-rfc6506bis
Htmlized:        http://tools.ietf.org/html/dr= aft-ietf-ospf-rfc6506bis-00


Abstract:
  Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechan= ism
  for authenticating protocol packets.  This behavior is dif= ferent from
  authentication mechanisms present in other routing protocols (O= SPFv2,
  Intermediate System to Intermediate System (IS-IS), RIP, and Ro= uting
  Information Protocol Next Generation (RIPng)).  In some en= vironments,
  it has been found that IPsec is difficult to configure and main= tain
  and thus cannot be used.  This document defines an alterna= tive
  mechanism to authenticate OSPFv3 protocol packets so that OSPFv= 3 does
  not only depend upon IPsec for authentication.  This docum= ent
  obsoletes RFC 6506.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--_000_94A203EA12AECE4BA92D42DBFFE0AE47030127F1eusaamb101erics_-- From acee.lindem@ericsson.com Mon Aug 19 07:57: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 EEDA311E8294 for ; Mon, 19 Aug 2013 07:57:18 -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 4C57UCgM2068 for ; Mon, 19 Aug 2013 07:57:13 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id EC76221F935A for ; Mon, 19 Aug 2013 07:56:55 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-09-52123237beda Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 8E.57.09414.73232125; Mon, 19 Aug 2013 16:56:55 +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, 19 Aug 2013 10:56:49 -0400 From: Acee Lindem To: OSPF List Thread-Topic: New Version Notification for draft-ietf-ospf-ospfv3-autoconfig-04.txt Thread-Index: AQHOnOtLIca8Q60WI0mYWieSFol5Pg== Date: Mon, 19 Aug 2013 14:56:48 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470302A0AE@eusaamb101.ericsson.se> References: <20130819144920.12890.95893.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: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470302A0AEeusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyuXRPiK65kVCQQddWYYuWe/fYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcf3nRcaCr44VlyaeZWpgnGnZxcjJISFgIvH+ynMmCFtM4sK9 9WxdjFwcQgJHGSWunN7HAuEsZ5Ro/vmGEaSKTUBH4vmjf8wgtoiArMTSJftZQWxhgVCJrz3P GSHioRKrtixlhbD1JH7/WgIWZxFQlZhyaDaYzSvgK/FpwzF2EFtIwFFi7ePjbCA2I9AV30+t AbuIWUBc4taT+VDXCUgs2XOeGcIWlXj5+B8rhK0sseTJfhaI+nyJqX/PMkPMF5Q4OfMJywRG 4VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx5D9VpL/Fn3mxFZzQJGjlWMHKXFqWW5 6UYGmxiBsXJMgk13B+Oel5aHGKU5WJTEeVfpnQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wLhL4s3mwplfb+yQ5/dnMw2JvH+u+8DPiWU6yVbnzxoesD9yS3buDyN32Wnnttfoip5uVP+5 uCNz1QMTKa1Jd6rEnmzXYT9+bHO/zIstW073zqqL/u5uaHIu9X3dwWKfdr2I7Ouuyi93b764 tiTDatE2/S8xhU3NN4KFHno3LDD2cd993XzlYyUlluKMREMt5qLiRAAkwH5jYwIAAA== Subject: [OSPF] Fwd: New Version Notification for draft-ietf-ospf-ospfv3-autoconfig-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: Mon, 19 Aug 2013 14:57:19 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470302A0AEeusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As I stated at the Berlin OSPF WG meeting, we intend to progress this draft= in the near future. With the Homenet interop activities, we have several i= mplementations. Also, other autoconfiguration drafts are based on this draf= t as a foundation. The only functional change from the -02 version is that I'm now allowing no= rmal OSPF stale LSA processing to handle after the resolution of an OSPFv3 = Router ID conflict. 6.3. Duplicate Router ID Resolution The OSPFv3 Router selected to resolve the duplicate OSPFv3 Router ID condition must select a new OSPFv3 Router ID. After selecting a new Router ID, all self-originated LSAs MUST be reoriginated, and any OSPFv3 neighbor adjacencies MUST be reestablished. The OSPFv3 router retaining the Router ID causing the conflict will reoriginate or purge stale any LSAs as described in Section 13.4 [OSPFV2]. Thanks, Acee Begin forwarded message: From: > Date: August 19, 2013 10:49:20 AM EDT To: Jari Arkko >, Acee Li= ndem > Subject: New Version Notification for draft-ietf-ospf-ospfv3-autoconfig-04.= txt A new version of I-D, draft-ietf-ospf-ospfv3-autoconfig-04.txt has been successfully submitted by Acee Lindem and posted to the IETF repository. Filename: draft-ietf-ospf-ospfv3-autoconfig Revision: 04 Title: OSPFv3 Auto-Configuration Creation date: 2013-08-19 Group: ospf Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3= -autoconfig-04.txt Status: http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-aut= oconfig Htmlized: http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-autoconf= ig-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-ospfv3-= autoconfig-04 Abstract: OSPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_94A203EA12AECE4BA92D42DBFFE0AE470302A0AEeusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable As I stated at the Berlin OSPF WG meeting, we intend to progress this draft= in the near future. With the Homenet interop activities, we have several i= mplementations. Also, other autoconfiguration drafts are based on this draf= t as a foundation. 
The only functional change from the -02 version is that I'm now allowi= ng normal OSPF stale LSA processing to handle after the resolution of an OS= PFv3 Router ID conflict. 

6.3.  Duplicate Router ID Resolution

   The OSPFv3 Router selected to resolve the duplicate OSPFv3 Router ID
   condition must select a new OSPFv3 Router ID.  After selecting a new
   Router ID, all self-originated LSAs MUST be reoriginated, and any
   OSPFv3 neighbor adjacencies MUST be reestablished.  The OSPFv3 router
   retaining the Router ID causing the conflict will reoriginate or
   purge stale any LSAs as described in Section 13.4 [OSPFV2].

Thanks,
Acee 


Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Date: Augus= t 19, 2013 10:49:20 AM EDT
To: Jari = Arkko <jari.arkko@piuha.net&= gt;, Acee Lindem <acee.linde= m@ericsson.com>
Subject: Ne= w Version Notification for draft-ietf-ospf-ospfv3-autoconfig-04.txt


A new version of I-D, draft-ietf-ospf-ospfv3-autoconfig-04.txt
has been successfully submitted by Acee Lindem and posted to the
IETF repository.

Filename: d= raft-ietf-ospf-ospfv3-autoconfig
Revision: 0= 4
Title: OSPFv3 Auto-Con= figuration
Creation date: 2013-08-19
Group: ospf
Number of pages: 17
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-= autoconfig-04.txt
Status:          http://dat= atracker.ietf.org/doc/draft-ietf-ospf-ospfv3-autoconfig
Htmlized:        http://tools.ietf.org/= html/draft-ietf-ospf-ospfv3-autoconfig-04
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-ospfv3-autoconfig-= 04

Abstract:
  OSPFv3 is a candidate for deployments in environments where aut= o-
  configuration is a requirement.  One such environment is t= he IPv6
  home network where users expect to simply plug in a router and = have
  it automatically use OSPFv3 for intra-domain routing.  Thi= s document
  describes the necessary mechanisms for OSPFv3 to be self-config= uring.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--_000_94A203EA12AECE4BA92D42DBFFE0AE470302A0AEeusaamb101erics_-- From acee.lindem@ericsson.com Thu Aug 29 07:58:09 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 2969211E811A for ; Thu, 29 Aug 2013 07:58:07 -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 1nX3eG5JHyqH for ; Thu, 29 Aug 2013 07:57:55 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 676ED11E8113 for ; Thu, 29 Aug 2013 07:57:51 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-7f-521f616e5035 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E0.DF.09414.E616F125; Thu, 29 Aug 2013 16:57:50 +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, 29 Aug 2013 10:57:50 -0400 From: Acee Lindem To: OSPF List Thread-Topic: Mail lost yesterday Thread-Index: AQIiuf/NPVJ0u+Yu4la7frHQKSZfMg== Date: Thu, 29 Aug 2013 14:57:48 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030370B0@eusaamb101.ericsson.se> References: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> 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_94A203EA12AECE4BA92D42DBFFE0AE47030370B0eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyuXRPiG5eonyQwftvJhYt9+6xOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/nk38wFdzwqLuy7yNLA+Nupi5GTQ0LAROL+vZdsELaYxIV7 64FsLg4hgaOMEv+3nmSHcJYzSpz61MMIUsUmoCPx/NE/ZhBbREBWYumS/awgtrCAokT7rQms EHFFiTeHHzNB2HoSs9b/B7NZBFQlZr94B2bzCvhKvHx3GcwWErCSmPtiDpjNCHTF91NrwGxm AXGJW0/mM0FcJyCxZM95ZghbVOLl43+sELayxJIn+1kg6vMlXuzcwAgxX1Di5MwnLBMYhWch GTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHgM1Wst8erLeyZkNQsYOVYxcpQWp5blphsZ bGIExsoxCTbdHYx7XloeYpTmYFES512ldyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Na Sv6frK1e17jvLPyQcf5XoVeqQ8nu6Iorv+PXKz+vzOGeOUehj7l1Mocj1ye9CXc1/9s+POB8 0Tdd7G5pW51tNNNt4WU11UJSM6e+NqlUjj60Jm7Ti65l25SPr5r5J07Pt1p6Pu/E4ABzy3Ie Oaf3osc4FkdenOV4v8fk1I13gbYiFr/YjJRYijMSDbWYi4oTAQxdq4ZjAgAA Subject: [OSPF] Fwd: Mail lost yesterday 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, 29 Aug 2013 14:58:09 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE47030370B0eusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI... In case, you sent mail to the list yesterday. Acee Begin forwarded message: From: Adrian Farrel > Date: August 29, 2013 10:46:09 AM EDT Resent-To: >, >, >, >, >, >, >, >, >, = >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, >, > To: > Subject: FW: Mail lost yesterday Reply-To: > For those of you who haven't noticed the message from Steve Young in your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific Time yesterday seems to have been lost. Aside from needing to re-send all mail you personally sent during that time period, you also need to inform your working groups. --_000_94A203EA12AECE4BA92D42DBFFE0AE47030370B0eusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable FYI... In case, you sent mail to the list yesterday. 
Acee 

Begin forwarded message:

From: Adria= n Farrel <adrian@olddog.co.uk= >
Date: Augus= t 29, 2013 10:46:09 AM EDT
Resent-To: <<= a href=3D"mailto:jhaas@pfrc.org">jhaas@pfrc.org>, <nobo@cisco.com>, <dbrungard@att.com>, <lberger@labn.net>, <hadi@mojatatu.com>, <damascene.joachimpilla= i@verizon.com>, <akatlas@j= uniper.net>, <edc@google.com>, <shares@ndzh.com>, <jgs@juniper.net>, <chopps@rawdofmt.org>, <hannes@juniper.net>, <jmh@joelhalpern.com>, <bew@cisco.com>, <nabil.n.bitar@verizon.com>, <<= a href=3D"mailto:giheron@cisco.com">giheron@cisco.com>, <thomas.morin@orange.com>, <martin.vigoureu= x@alcatel-lucent.com>, <macker@itd.nrl.navy.mil>, <sratliff@cisco.com>, <swal= low@cisco.com>, <loa@pi.nu>, <rcallon@juniper.net>, <bensons@queuefull.net>, <matthew.bocci@alcatel-lucent.com>, <akr@cisco.com>, <acee.lindem@ericsson.com>, <jpv@cisco.com>, <julien.meuric@orange.com>, <mmcbride7@gmail.com>, <stig@venaas.com>, <matthew.bocci@alcatel-lucent.= com>, <andrew.g.mal= is@verizon.com>, <jpv@cisco.com<= /a>>, <mcr+ietf@sandelman.ca= >, <aretana@cisco.com>= ;, <akatlas@gmail.com>, <= Sandra.Murphy@sparta.com>= ;, <morrowc@ops-netman.net&g= t;, <stbryant@cisco.com>, &= lt;adrian@olddog.co.uk>
To: <<= a href=3D"mailto:rtg-chairs@ietf.org">rtg-chairs@ietf.org>
Subject: FW= : Mail lost yesterday
Reply-To: <<= a href=3D"mailto:adrian@olddog.co.uk">adrian@olddog.co.uk>

For those of you who haven't noticed the message from Steve Young in your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific
Time yesterday seems to have been lost. Aside from needing to re-send
all mail you personally sent during that time period, you also need to
inform your working groups.


--_000_94A203EA12AECE4BA92D42DBFFE0AE47030370B0eusaamb101erics_--