From manav.bhatia@alcatel-lucent.com Sun Mar 6 16:46:52 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A75628C0CF for ; Sun, 6 Mar 2011 16:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.822 X-Spam-Level: X-Spam-Status: No, score=-6.822 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+nmxWD2G3pq for ; Sun, 6 Mar 2011 16:46:51 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 99AB73A68AC for ; Sun, 6 Mar 2011 16:46:51 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p270m0Qb024796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 6 Mar 2011 18:48:03 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p270m0vi007026 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 7 Mar 2011 06:18:00 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Mon, 7 Mar 2011 06:18:00 +0530 From: "Bhatia, Manav (Manav)" To: "ospf@ietf.org" Date: Mon, 7 Mar 2011 06:18:19 +0530 Thread-Topic: A Generic Mechanism to solve Inter-Session Replay Attacks Thread-Index: AcvcYPGWaItCj65sR22n/VTqiQ7sbQAACkUg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCC81D03@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [OSPF] FW: A Generic Mechanism to solve Inter-Session Replay Attacks X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 00:46:52 -0000 This is also applicable to the OSPF-AT work underway in the OSPF WG. Cheers, Manav > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Bhatia, Manav (Manav) > Sent: Monday, March 07, 2011 6.15 AM > To: karp@ietf.org > Subject: [karp] A Generic Mechanism to solve Inter-Session=20 > Replay Attacks >=20 > Hi, >=20 > One of the requirements listed in the KARP threat-reqs=20 > document is to work on a mechanism that solves inter-session=20 > replay attacks in the routing and the signaling protocols.=20 > Sam, Dacheng and I have written a small draft that describes=20 > how this can be done. >=20 > URL for the draft: > http://www.ietf.org/id/draft-bhz-karp-inter-session-replay-00.txt >=20 > Would be great to hear some feedback from the WG. >=20 > Cheers, Manav >=20 > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India >=20 > =20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From akr@cisco.com Tue Mar 8 12:22:28 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1174B3A698F for ; Tue, 8 Mar 2011 12:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbBga8MD9M9O for ; Tue, 8 Mar 2011 12:22:27 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B736B3A6988 for ; Tue, 8 Mar 2011 12:22:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=akr@cisco.com; l=130; q=dns/txt; s=iport; t=1299615822; x=1300825422; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=DdTx95J2gSjs0e97M+Rj20a2s+A+Kn48OZq529Lp7N0=; b=JgKJa/atHotUIgFlGnMQXntgffXgahoX3xZNdH4kQAJ/b52Eg8g2IdEt MeGuLvi13zDq2PIe6JJt5KHYiB+H8jrlNQYGz2j85dortvqv+ySxutEMt 2dpNGGPOdoCrJpx0A4sDNtXQ6SfY3fYJFYlg7Z8ysrECUOHgY9yZdO/6N E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcKAIUedk2rRN+J/2dsb2JhbACCeKNpdIhBmn+cL4VjBIUdhxU X-IronPort-AV: E=Sophos;i="4.62,285,1297036800"; d="scan'208";a="272728142" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2011 20:23:39 +0000 Received: from dhcp-171-70-225-242.cisco.com (dhcp-171-70-225-242.cisco.com [171.70.225.242]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p28KNdYr003366 for ; Tue, 8 Mar 2011 20:23:39 GMT Message-ID: <4D76904B.5040704@cisco.com> Date: Tue, 08 Mar 2011 12:23:39 -0800 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: "ospf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OSPF] IETF 80 OSPF WG Meeting Agenda Slots X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 20:22:28 -0000 We have a 2 hr slot on tuesday afternoon @1pm. If you would like a slot, please let me or Acee know. Regards, Acee & Abhay From ben@niven-jenkins.co.uk Wed Mar 16 00:42:56 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267C93A682D; Wed, 16 Mar 2011 00:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.663 X-Spam-Level: X-Spam-Status: No, score=-102.663 tagged_above=-999 required=5 tests=[AWL=-1.060, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnHQYTcLPW0p; Wed, 16 Mar 2011 00:42:55 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 5DC2D3A6826; Wed, 16 Mar 2011 00:42:55 -0700 (PDT) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.203]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PzlP1-0006Ef-E4; Wed, 16 Mar 2011 07:44:19 +0000 From: Benjamin Niven-Jenkins Content-Type: text/plain; charset=us-ascii Message-Id: <0636D1EB-942D-4416-858E-E698863B141C@niven-jenkins.co.uk> Date: Wed, 16 Mar 2011 07:44:17 +0000 To: L3VPN WG mailing list , ospf@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: [OSPF] Joint L3VPN & OSPF WG LC for draft-ietf-l3vpn-ospfv3-pece-07 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 07:42:56 -0000 L3VPNers & OSPFers, You may recall that back in January 2010 we pulled = draft-ietf-l3vpn-ospfv3-pece-04 out of the RFC Editor's queue because we = had forgotten to solicit a review from the OSPF WG. See = http://www.ietf.org/mail-archive/web/ospf/current/msg05658.htm for more = info on that. The OSPF WG raised some comments on the draft, which has gone through a = few revisions and draft-ietf-l3vpn-ospfv3-pece-07 is thought to address = all the previous comments raised. This e-mail is therefore the start of a joint L3VPN & OSPF WG Last Call = for the updated draft. It is restricted to changes made since the last = review (i.e. changes between -04 and -07). Due to the proximity of IETF80 we are allowing 4 weeks for the LC. = Please provide any further comments on the changes by midnight PDT on = the 13th April 2011. You can view -07 of the draft here: http://tools.ietf.org/id/draft-ietf-l3vpn-ospfv3-pece-07.txt You can view a diff between -04 and -07 here: = http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-l3vpn-ospfv3-pece-04&url2=3D= draft-ietf-l3vpn-ospfv3-pece-07 Thanks Ben (on behalf of the L3VPN & OSPF chairs) From acee.lindem@ericsson.com Thu Mar 24 13:08:20 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE993A68C3 for ; Thu, 24 Mar 2011 13:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.864 X-Spam-Level: X-Spam-Status: No, score=-3.864 tagged_above=-999 required=5 tests=[AWL=1.734, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9GJ9FOA4++w for ; Thu, 24 Mar 2011 13:08:19 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 5D8A328C114 for ; Thu, 24 Mar 2011 13:08:19 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2OK9qgj000637 for ; Thu, 24 Mar 2011 15:09:54 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.177]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 24 Mar 2011 16:09:46 -0400 From: Acee Lindem To: "ospf@ietf.org" Date: Thu, 24 Mar 2011 16:09:43 -0400 Thread-Topic: Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt Thread-Index: AcvqX2te7VKAvQeZSkq1b6jNDq9x2w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-39-567636946"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 24 Mar 2011 20:08:20 -0000 --Apple-Mail-39-567636946 Content-Type: multipart/alternative; boundary=Apple-Mail-38-567636930 --Apple-Mail-38-567636930 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This draft was presented in Beijing. Since that time, we've had numerous = discussions with the BEHAVE WG chairs and they would support this work. = RFC 6052 describes the IPv4<->IPv6 translation and this draft proposes = using RFC 5838 (Support of Address Families in OSPFv3) to advertise = translated IPv4 prefixes from isolated IPv4 routing domains. The = intended status is informational. Please indicate whether or not you = support this becoming an OSPF WG draft. Thanks, Acee --Apple-Mail-38-567636930 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This draft was = presented in Beijing. Since that time, we've had numerous discussions = with the BEHAVE WG chairs and they would support this = work. RFC 6052 describes the IPv4<->IPv6 = translation and this draft proposes using RFC 5838 (Support of = Address Families in OSPFv3) to advertise translated IPv4 prefixes from isolated IPv4 routing = domains. The intended status is informational. Please indicate = whether or not you support this = becoming an OSPF WG = draft.
Thanks,
Acee

= --Apple-Mail-38-567636930-- --Apple-Mail-39-567636946 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMyNDIwMDk0NFowIwYJKoZI hvcNAQkEMRYEFLVWDGx8q5lc2SkVpUkTHFmazdY5MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgEPn/JNHd+Ubr/2OV09AV5ctw95i7aij1rNvcBaBI042mU/MKwDoohcYafhRxtwB rmeOMp7Y0cp9xaBcZpZj4tMJb7XK92yuhsUzImj2+FkwawxBj/N2JFthRLXO+D+KBeeN5m1fghKV uz0CaItIruP7aNuIHQAAsA7SY9FOWcCoAAAAAAAA --Apple-Mail-39-567636946-- From aretana@cisco.com Fri Mar 25 12:54:12 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01453A6838 for ; Fri, 25 Mar 2011 12:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHUmOjSse1A9 for ; Fri, 25 Mar 2011 12:54:11 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8E1C13A682D for ; Fri, 25 Mar 2011 12:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aretana@cisco.com; l=8537; q=dns/txt; s=iport; t=1301082947; x=1302292547; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=8ZLI47AghgT3SeT8Hi3cPvS5cV8GU8FNcaduBfWuWno=; b=Ygee1T+z+th4FOdeYIigOR7lYydKy2t6vNHYEdVu4o12Eq9lLNrI4y0g FMHwV42Xl/Tx2izaz7xAT7nyggl+iNpZIoMMOKf4FY9Z2pHEDSmlaAsFr 6KfOrKd8fH1V0tHC9tkCzbiU7Uu5QzlC35NzKEqr000RcknKr3/ot6wcL U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEBAAXzjE2tJXG8/2dsb2JhbACCYZVDjT93p1qcQ4VpBIU6ixU X-IronPort-AV: E=Sophos;i="4.63,244,1299456000"; d="scan'208,217";a="281390892" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-4.cisco.com with ESMTP; 25 Mar 2011 19:55:45 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2PJtjgj029010; Fri, 25 Mar 2011 19:55:45 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Mar 2011 14:55:45 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEB26.A1023139" Date: Fri, 25 Mar 2011 14:55:38 -0500 Message-ID: <1D23749D4168CC4D8B8652397B5F643204DA67E9@XMB-RCD-206.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt Thread-Index: AcvqX2te7VKAvQeZSkq1b6jNDq9x2wAxynGQ References: From: "Alvaro Retana (aretana)" To: "Acee Lindem" , X-OriginalArrivalTime: 25 Mar 2011 19:55:45.0524 (UTC) FILETIME=[A1282B40:01CBEB26] Subject: Re: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2011 19:54:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEB26.A1023139 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. =20 Alvaro. =20 From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Thursday, March 24, 2011 4:10 PM To: ospf@ietf.org Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt =20 This draft was presented in Beijing. Since that time, we've had numerous discussions with the BEHAVE WG chairs and they would support this work. RFC 6052 describes the IPv4<->IPv6 translation and this draft proposes using RFC 5838 (Support of Address Families in OSPFv3) to advertise translated IPv4 prefixes from isolated IPv4 routing domains. The intended status is informational. Please indicate whether or not you support this becoming an OSPF WG draft. Thanks, Acee =20 =20 ------_=_NextPart_001_01CBEB26.A1023139 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

Alvaro.

 

From:= = ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: Thursday, March 24, 2011 4:10 PM
To: ospf@ietf.org
Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt

 

This draft was presented in =
Beijing. Since that time, we've had numerous discussions with the BEHAVE =
WG chairs and they would support this work. RFC 6052 describes the =
IPv4<->IPv6 translation and this draft proposes using RFC =
5838 (Support of Address Families in OSPFv3) to advertise =
translated IPv4 prefixes from isolated IPv4 routing domains. The =
intended status is informational. Please indicate whether or not =
you support this becoming an OSPF WG =
draft.

Thanks,

Acee

 

 

------_=_NextPart_001_01CBEB26.A1023139-- From acee.lindem@ericsson.com Fri Mar 25 14:13:07 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D77828C0F5 for ; Fri, 25 Mar 2011 14:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4thcpGOvUuzt for ; Fri, 25 Mar 2011 14:13:06 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 8BB1F28C0CE for ; Fri, 25 Mar 2011 14:13:06 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p2PLEdKH030427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 25 Mar 2011 16:14:41 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.177]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 25 Mar 2011 17:14:38 -0400 From: Acee Lindem CC: "ospf@ietf.org" Date: Fri, 25 Mar 2011 17:14:35 -0400 Thread-Topic: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt Thread-Index: AcvrMaV+jpQ7DEKmRVG2qvFet4pxyg== Message-ID: References: <1D23749D4168CC4D8B8652397B5F643204DA67E9@XMB-RCD-206.cisco.com> In-Reply-To: <1D23749D4168CC4D8B8652397B5F643204DA67E9@XMB-RCD-206.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-8-657928235"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: Re: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2011 21:13:07 -0000 --Apple-Mail-8-657928235 Content-Type: multipart/alternative; boundary=Apple-Mail-7-657928211 --Apple-Mail-7-657928211 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Speaking as WG member - Support. Acee=20 On Mar 25, 2011, at 3:55 PM, Alvaro Retana (aretana) wrote: > Support. > =20 > Alvaro. > =20 > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf = Of Acee Lindem > Sent: Thursday, March 24, 2011 4:10 PM > To: ospf@ietf.org > Subject: [OSPF] Routing for IPv4-embedded IPv6 Packets - = draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt > =20 > This draft was presented in Beijing. Since that time, we've had = numerous discussions with the BEHAVE WG chairs and they would support = this work. RFC 6052 describes the IPv4<->IPv6 translation and this draft = proposes using RFC 5838 (Support of Address Families in OSPFv3) to = advertise translated IPv4 prefixes from isolated IPv4 routing domains. = The intended status is informational. Please indicate whether or not you = support this becoming an OSPF WG draft. > Thanks, > Acee > =20 > =20 --Apple-Mail-7-657928211 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Speaking as WG member - = Support.
Acee 
On Mar 25, 2011, at 3:55 PM, Alvaro = Retana (aretana) wrote:

 ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org= ] On Behalf Of Acee = Lindem
Sent: Thursday, March 24, 2011 = 4:10 PM
To: ospf@ietf.org
Subject: [OSPF] Routing for = IPv4-embedded IPv6 Packets - = draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt
=
 
This draft was presented in Beijing. Since that time, =
we've had numerous discussions with the BEHAVE WG chairs and they would =
support this work. RFC 6052 describes the IPv4<->IPv6 =
translation and this draft proposes using RFC 5838 (Support of =
Address Families in OSPFv3) to advertise translated IPv4 prefixes =
from isolated IPv4 routing domains. The intended status is =
informational. Please indicate whether or not you support this =
becoming an OSPF WG draft.
Thanks,
X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F60C3A6781 for ; Fri, 25 Mar 2011 15:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_44=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2FbmeDOC46a for ; Fri, 25 Mar 2011 15:08:02 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0824A3A6765 for ; Fri, 25 Mar 2011 15:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=504; q=dns/txt; s=iport; t=1301090977; x=1302300577; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=aqcNgN6gP1W1IEv9SPK2ZNtyFyEcjNQE/OSQd6HvGtY=; b=K52JuhTgPcllFNPmabykXXGc20xcohqZ9G084obhv45vV9oiiz6CgKYf aD6+WI0DmjI65EzAOHI3lLDv5/VFKFPATVF4nBAMc1ijvP+QkXlzBCFPJ tdG++ZayjET6oqnQRNFJvsfex8SV/GDAeDRLqNDtD3wjaxOU7o7P8sMk+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoHAHARjU2tJXHB/2dsb2JhbACYYox+d4hNnlKCbw4BmT2FaQSMdYNU X-IronPort-AV: E=Sophos;i="4.63,245,1299456000"; d="scan'208";a="281447231" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 25 Mar 2011 22:09:37 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2PM9aIu013836 for ; Fri, 25 Mar 2011 22:09:36 GMT Message-ID: <4D8D12A6.2080008@cisco.com> Date: Fri, 25 Mar 2011 23:09:42 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 22:08:03 -0000 Support. R. > This draft was presented in Beijing. Since that time, we've had numerous discussions with the BEHAVE WG chairs and they would support this work. RFC 6052 describes the IPv4<->IPv6 translation and this draft proposes using RFC 5838 (Support of Address Families in OSPFv3) to advertise translated IPv4 prefixes from isolated IPv4 routing domains. The intended status is informational. Please indicate whether or not you support this becoming an OSPF WG draft. > > Thanks, > Acee From akr@cisco.com Fri Mar 25 15:26:28 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CF028C0CE for ; Fri, 25 Mar 2011 15:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.998 X-Spam-Level: X-Spam-Status: No, score=-108.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekZklL1eruTj for ; Fri, 25 Mar 2011 15:26:27 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9D9583A67B3 for ; Fri, 25 Mar 2011 15:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=akr@cisco.com; l=2805; q=dns/txt; s=iport; t=1301092083; x=1302301683; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=TJ9VjCWAVCcS0OxlIf1oUyptQsY2aclMNnKmgW4CFpw=; b=m/f0eHtb4o9Z0nafRa/7NZWOzl9j8OZuExvmrmboLu7AgqQXk7dWguwd RXg+hT5Gvnj3ekevO+OTEqGk6nmRYC1FR7WrePUXvSJo+djxfUakdX+ae Q+Zk52emuXRgmpcOxJsyMAwsf/1t7pRrKckJCuOIm37aqoPBL9I70JICC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOkVjU2rRDoJ/2dsb2JhbAClYHenEJw5hWkEhTqHOw X-IronPort-AV: E=Sophos;i="4.63,245,1299456000"; d="scan'208,217";a="324748220" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2011 22:28:03 +0000 Received: from sjc-vpn3-1450.cisco.com (sjc-vpn3-1450.cisco.com [10.21.69.170]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2PMS3Jl013203; Fri, 25 Mar 2011 22:28:03 GMT Message-ID: <4D8D16F3.4000508@cisco.com> Date: Fri, 25 Mar 2011 15:28:03 -0700 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Acee Lindem References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010005050106090900070102" Cc: "ospf@ietf.org" Subject: Re: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2011 22:26:28 -0000 This is a multi-part message in MIME format. --------------010005050106090900070102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Support (speaking as WG member).. On 3/24/11 1:09 PM, Acee Lindem wrote: > This draft was presented in Beijing. Since that time, we've had numerous discussions with the BEHAVE WG chairs and they would support this work.RFC 6052 describes the IPv4<->IPv6 translation and this draft proposes using RFC 5838 (Support of Address Families in OSPFv3) toadvertise translated IPv4 prefixes from isolated IPv4 routing domains. The intended status is informational. Please indicate whether or not yousupport this becoming an OSPF WG draft. > Thanks, > Acee > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --------------010005050106090900070102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Support

(speaking as WG member)..

On 3/24/11 1:09 PM, Acee Lindem wrote: 
This draft was presented in Beijing. Since that time, we've had numerous discussions with the BEHAVE WG chairs and they would support this work. RFC 6052 describes the IPv4<->IPv6 translation and this draft proposes using RFC 5838 (Support of Address Families in OSPFv3) to advertise translated IPv4 prefixes from isolated IPv4 routing domains. The intended status is informational. Please indicate whether or not you support this becoming an OSPF WG draft.
Thanks,
Acee



_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
--------------010005050106090900070102-- From christian.jacquenet@orange-ftgroup.com Sat Mar 26 04:18:27 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C113A67EE for ; Sat, 26 Mar 2011 04:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_BACKHAIR_44=1, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep1shjexPSvQ for ; Sat, 26 Mar 2011 04:18:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 09FD23A67D6 for ; Sat, 26 Mar 2011 04:18:25 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 4155E264258; Sat, 26 Mar 2011 12:20:00 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 276F3238055; Sat, 26 Mar 2011 12:20:00 +0100 (CET) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Sat, 26 Mar 2011 12:20:00 +0100 From: To: Acee Lindem , "ospf@ietf.org" Date: Sat, 26 Mar 2011 12:19:57 +0100 Thread-Topic: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt Thread-Index: AcvqX2te7VKAvQeZSkq1b6jNDq9x2wBSEMZg Message-ID: <25738_1301138400_4D8DCBE0_25738_42262_1_983A1D8DA0DA5F4EB747BF34CBEE5CD14AE0BD10CE@PUEXCB1C.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_983A1D8DA0DA5F4EB747BF34CBEE5CD14AE0BD10CEPUEXCB1Cnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.26.100323 Subject: Re: [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 11:18:27 -0000 --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD14AE0BD10CEPUEXCB1Cnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I also support the adoption of the draft as a WG document. Cheers, Christian. ________________________________ De : ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] De la part de Ace= e Lindem Envoy=E9 : jeudi 24 mars 2011 21:10 =C0 : ospf@ietf.org Objet : [OSPF] Routing for IPv4-embedded IPv6 Packets - draft-cheng-ospf-ip= v4-embedded-ipv6-routing-03.txt This draft was presented in Beijing. Since that time, we've had numerous di= scussions with the BEHAVE WG chairs and they would support this work. RFC 6= 052 describes the IPv4<->IPv6 translation and this draft proposes using RFC= 5838 (Support of Address Families in OSPFv3) to advertise translated IPv4 = prefixes from isolated IPv4 routing domains. The intended status is informa= tional. Please indicate whether or not you support this becoming an OSPF WG= draft. Thanks, Acee ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD14AE0BD10CEPUEXCB1Cnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
 
I also support the adoption of the draft as a= WG=20 document.
 
Cheers,
 
Christian.

De : ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] De la part de Acee=20 Lindem
Envoy=E9 : jeudi 24 mars 2011 21:10
=C0 = :=20 ospf@ietf.org
Objet : [OSPF] Routing for IPv4-embedded IPv= 6=20 Packets -=20 draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt

This draft was presented in=
 Beijing. Since that time, we've had numerous discussions with the BEHAVE W=
G chairs and they would support this work. RFC 6052 describes the IPv=
4<->IPv6 translation and this draft proposes using RFC 5838 (Sup=
port of Address Families in OSPFv3) to advertise translat=
ed IPv4 prefixes from isolated IPv4 routing domains. The intended stat=
us is informational. Please indicate whether or not you s=
upport this becoming an OSPF WG draft.
Thanks,
Acee


****************************************=
****************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris=
 les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) men=
tionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve=
uillez immediatement le signaler  a l expediteur et effacer ce message=20
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans=
 ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment=
 s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout vi=
rus.

IMPORTANT.This e-mail message and any attachments are strictly confidential=
 and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(=
s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not b=
e liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
***************************************************************************=
*****
--_000_983A1D8DA0DA5F4EB747BF34CBEE5CD14AE0BD10CEPUEXCB1Cnante_-- From zzhang@juniper.net Mon Mar 28 07:48:12 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6761D3A68F3 for ; Mon, 28 Mar 2011 07:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md0fhh8n2JRt for ; Mon, 28 Mar 2011 07:48:11 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 3A5E83A6863 for ; Mon, 28 Mar 2011 07:48:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTZCgCapgYLNQPWfuNm7/dEalpqBVyJIB@postini.com; Mon, 28 Mar 2011 07:49:49 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Mar 2011 07:47:02 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 28 Mar 2011 10:48:29 -0400 From: "Jeffrey (Zhaohui) Zhang" To: Acee Lindem , "Abhay Roy (akr)" Date: Mon, 28 Mar 2011 10:48:24 -0400 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcvSu75+VNuBUribS4ij2HE3LTP6sQamjntw Message-ID: <13205C286662DE4387D9AF3AC30EF456D340239330@EMBX01-WF.jnpr.net> References: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com> <4D5474C5.1050107@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 14:48:12 -0000 WG chairs and members, As Acee mentioned below, this optimization is a reasonable, simple and gene= ral solution for a valid probem, and is really not conflicting with MANET. As a result, we would like to request again for WG's acceptance of this wor= k. Thanks. Jeffrey, Nischal, Lili.=20 > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Tuesday, February 22, 2011 7:10 PM > To: Nischal Sheth > Cc: Alvaro Retana (aretana); Jeffrey (Zhaohui) Zhang; ospf@ietf.org > Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >=20 > Speaking as a WG member, I really don't see this hybrid=20 > interface optimization as conflicting with the problem space=20 > covered by the MANET draft.=20 > Thanks, > Acee=20 > On Feb 10, 2011, at 6:29 PM, Nischal Sheth wrote: >=20 > > On 1/6/2011 2:26 PM, Alvaro Retana (aretana) wrote: > >=20 > >> You don't need to implement everything in the rfc to support the > >> interface functionality. Most of the work in the rfc is=20 > oriented at > >> reducing the overhead on the wire (Incremental Hellos,=20 > Smart Peering) or > >> at addressing the cases where not all the nodes are=20 > visible (Overlapping > >> Relays). > >>=20 > >> If you don't care about reducing the overhead and can=20 > guarantee that all > >> the nodes are visible, then the interface definition is enough. ;-) > >> That reduces to taking advantage of the broadcast=20 > characteristics for > >> flooding, but using p2p adjacencies -- which would be a=20 > lot easier to > >> operate because it is clearer what the relationship=20 > between the peers > >> w/the different metrics is. > >>=20 > >> In my mind the problem in your document is already solved. > >>=20 > >=20 > > Hi Alvaro, > >=20 > > If one were to use just the interface definition, we would=20 > end up with a=20 > > full mesh of adjacencies between all routers on the=20 > broadcast network. > > This is less desirable compared to the hybrid interface=20 > which requires=20 > > adjacencies only to the DR/BDR. > >=20 > > One would need to implement Smart Peering in order to=20 > reduce the number=20 > > of adjacencies on the MANET interface. However, doing so=20 > would result=20 > > in suboptimal routing unless you implement Unsynchronized=20 > Adjacencies. > > Finally, Unsynchronized Adjacencies requires a protocol=20 > extension which=20 > > is defined only for OSPFv3. > >=20 > > Based on the points above, I don't consider the MANET=20 > Interface to be a=20 > > true superset of the hybrid interface to solve the problem at hand. > >=20 > > -Nischal > >=20 >=20 > = From zzhang@juniper.net Mon Mar 28 07:52:05 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8A53A6A59 for ; Mon, 28 Mar 2011 07:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6ETo7hMRnE7 for ; Mon, 28 Mar 2011 07:52:03 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 624823A69CF for ; Mon, 28 Mar 2011 07:51:56 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTZCg7d1Xk/huigxccQlQULmyH3UR+/OS@postini.com; Mon, 28 Mar 2011 07:53:41 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Mar 2011 07:51:42 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 28 Mar 2011 10:53:08 -0400 From: "Jeffrey (Zhaohui) Zhang" To: 'Acee Lindem' , "'Abhay Roy (akr)'" Date: Mon, 28 Mar 2011 10:53:05 -0400 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcvSu75+VNuBUribS4ij2HE3LTP6sQamjntwAABZI5A= Message-ID: <13205C286662DE4387D9AF3AC30EF456D340239349@EMBX01-WF.jnpr.net> References: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com> <4D5474C5.1050107@juniper.net> <2F802BA76C16F746945F3E152126202EB1994CE086@EMBX01-WF.jnpr.net> In-Reply-To: <2F802BA76C16F746945F3E152126202EB1994CE086@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'ospf@ietf.org'" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 14:52:05 -0000 Sorry - forgot to emphasize that the proposed optimization only applies to = true-broadcast networks (including but not limited to wired networks), and = is not intended for true-MANET networks. Thanks. Jeffrey > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang=20 > Sent: Monday, March 28, 2011 4:48 PM > To: Acee Lindem; Abhay Roy (akr) > Cc: Alvaro Retana (aretana); ospf@ietf.org; Nischal Sheth; Lili Wang > Subject: RE: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >=20 > WG chairs and members, >=20 > As Acee mentioned below, this optimization is a reasonable,=20 > simple and general solution for a valid probem, and is really=20 > not conflicting with MANET. >=20 > As a result, we would like to request again for WG's=20 > acceptance of this work. >=20 > Thanks. > Jeffrey, Nischal, Lili.=20 >=20 > > -----Original Message----- > > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > > Sent: Tuesday, February 22, 2011 7:10 PM > > To: Nischal Sheth > > Cc: Alvaro Retana (aretana); Jeffrey (Zhaohui) Zhang; ospf@ietf.org > > Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type > >=20 > > Speaking as a WG member, I really don't see this hybrid=20 > > interface optimization as conflicting with the problem space=20 > > covered by the MANET draft.=20 > > Thanks, > > Acee=20 > > On Feb 10, 2011, at 6:29 PM, Nischal Sheth wrote: > >=20 > > > On 1/6/2011 2:26 PM, Alvaro Retana (aretana) wrote: > > >=20 > > >> You don't need to implement everything in the rfc to support the > > >> interface functionality. Most of the work in the rfc is=20 > > oriented at > > >> reducing the overhead on the wire (Incremental Hellos,=20 > > Smart Peering) or > > >> at addressing the cases where not all the nodes are=20 > > visible (Overlapping > > >> Relays). > > >>=20 > > >> If you don't care about reducing the overhead and can=20 > > guarantee that all > > >> the nodes are visible, then the interface definition is=20 > enough. ;-) > > >> That reduces to taking advantage of the broadcast=20 > > characteristics for > > >> flooding, but using p2p adjacencies -- which would be a=20 > > lot easier to > > >> operate because it is clearer what the relationship=20 > > between the peers > > >> w/the different metrics is. > > >>=20 > > >> In my mind the problem in your document is already solved. > > >>=20 > > >=20 > > > Hi Alvaro, > > >=20 > > > If one were to use just the interface definition, we would=20 > > end up with a=20 > > > full mesh of adjacencies between all routers on the=20 > > broadcast network. > > > This is less desirable compared to the hybrid interface=20 > > which requires=20 > > > adjacencies only to the DR/BDR. > > >=20 > > > One would need to implement Smart Peering in order to=20 > > reduce the number=20 > > > of adjacencies on the MANET interface. However, doing so=20 > > would result=20 > > > in suboptimal routing unless you implement Unsynchronized=20 > > Adjacencies. > > > Finally, Unsynchronized Adjacencies requires a protocol=20 > > extension which=20 > > > is defined only for OSPFv3. > > >=20 > > > Based on the points above, I don't consider the MANET=20 > > Interface to be a=20 > > > true superset of the hybrid interface to solve the=20 > problem at hand. > > >=20 > > > -Nischal > > >=20 > >=20 > > = From thomas.r.henderson@boeing.com Mon Mar 28 11:39:19 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4540B3A6825 for ; Mon, 28 Mar 2011 11:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.455 X-Spam-Level: X-Spam-Status: No, score=-106.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tBLg-9D9jEh for ; Mon, 28 Mar 2011 11:39:18 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 84A363A67D6 for ; Mon, 28 Mar 2011 11:39:18 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p2SIemV5021065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Mar 2011 11:40:48 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p2SIem3c010868; Mon, 28 Mar 2011 11:40:48 -0700 (PDT) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p2SIeml2010854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 28 Mar 2011 11:40:48 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Mon, 28 Mar 2011 11:40:48 -0700 From: "Henderson, Thomas R" To: "'Acee Lindem'" , Nischal Sheth , "Jeffrey (Zhaohui) Zhang" Date: Mon, 28 Mar 2011 11:40:47 -0700 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcvSu75+VNuBUribS4ij2HE3LTP6sQasXWow Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25B07D@XCH-NW-10V.nw.nos.boeing.com> References: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com> <4D5474C5.1050107@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 18:39:19 -0000 I don't have a problem with the proposal to specify a simpler interface typ= e for the use cases described. It seems preferable for a vendor to be able= to say that it fully implements a particular interface type rather than ha= ving to say that it implements an interface type but lacking features a,b,c= etc. There are many radio systems that perform routing below IP and provide a fu= ll broadcast-based abstraction, but for which the neighbor costs are unequa= l and it would be nice to be able to represent them that way in OSPF. More= over, people are now designing radio to router protocols to allow these une= qual costs to be dynamic and automatically computed.=20 It might be nice to define broadcast-oriented interface types progressively= as follows: 1) existing broadcast interface for equal-cost neighbors 2) the proposed hybrid interface for full mesh broadcast links with unequal= neighbor costs 3) correct the DR election and flooding behavior for links that may be part= ial mesh The above could all be separate interface types, and 2) and 3) could each b= e supplemented by additional capabilities: - optional radio-to-router control protocol to determine the unequal neighb= or costs or router priorities automatically - overhead reduction techniques such as differential hellos or partial topo= logy reporting Tom From acee.lindem@ericsson.com Tue Mar 29 03:24:04 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC993A690E for ; Tue, 29 Mar 2011 03:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[AWL=1.747, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZy+0VS8lwD3 for ; Tue, 29 Mar 2011 03:24:03 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 370633A6930 for ; Tue, 29 Mar 2011 03:24:03 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2TAPeJQ029451 for ; Tue, 29 Mar 2011 05:25:41 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.177]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 29 Mar 2011 06:25:34 -0400 From: Acee Lindem To: "ospf@ietf.org" Date: Tue, 29 Mar 2011 06:25:32 -0400 Thread-Topic: OSPF WG Meeting Scribe Thread-Index: Acvt+6M575FCJAaSTuSmoNdpHh/daw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-13-964585127"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [OSPF] OSPF WG Meeting Scribe X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 10:24:04 -0000 --Apple-Mail-13-964585127 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I would be great if someone would volunteer to be scribe. Thanks, Acee --Apple-Mail-13-964585127 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMyOTEwMjUzMlowIwYJKoZI hvcNAQkEMRYEFCFTBbujV4NkV8Ce+xF9JIjBhQQ7MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgBPiIQRxgiXPRRR6XQPWjno+dk0pioJh+LLh+qs0l+/GP2UXmxIBrDaD+n6QCreg S5FujAgaQvYZnhE5Vil1YNem9BZjic70oWMXMT/CrCGMRvxzZF44x4AM1EIIbITvZ12610AkH9lW NQ6Vn5NNq/PqtARKrYOt0sH59cPacBnPAAAAAAAA --Apple-Mail-13-964585127-- From zzhang@juniper.net Tue Mar 29 07:09:02 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E1F03A68DA for ; Tue, 29 Mar 2011 07:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 741IQuPOECjI for ; Tue, 29 Mar 2011 07:09:01 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id EBE4C3A67E3 for ; Tue, 29 Mar 2011 07:08:56 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTZHoWoSeVd++40H6SJIll7OqAi7xnjN4@postini.com; Tue, 29 Mar 2011 07:10:39 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 07:08:41 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 29 Mar 2011 10:10:10 -0400 From: "Jeffrey (Zhaohui) Zhang" To: "Henderson, Thomas R" , 'Acee Lindem' , Nischal Sheth Date: Tue, 29 Mar 2011 10:10:14 -0400 Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type Thread-Index: AcvSu75+VNuBUribS4ij2HE3LTP6sQasXWowACtAqPA= Message-ID: <13205C286662DE4387D9AF3AC30EF456D340385441@EMBX01-WF.jnpr.net> References: <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com> <4D5474C5.1050107@juniper.net> <7CC566635CFE364D87DC5803D4712A6C4CED25B07D@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CED25B07D@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 14:09:02 -0000 Tom, Thanks for your comments. A summary of our offlline discussion to feedback to this list. > The above could all be separate interface types, and 2) and=20 > 3) could each be supplemented by additional capabilities: > - optional radio-to-router control protocol to determine the=20 > unequal neighbor costs or router priorities automatically This is outside of OSPF scope, and already going on. > - overhead reduction techniques such as differential hellos=20 > or partial topology reporting.=20 This is the true-MANET situation and Alvaro is following up you on that. Thanks. Jeffrey > -----Original Message----- > From: Henderson, Thomas R [mailto:thomas.r.henderson@boeing.com]=20 > Sent: Monday, March 28, 2011 8:41 PM > To: 'Acee Lindem'; Nischal Sheth; Jeffrey (Zhaohui) Zhang > Cc: ospf@ietf.org > Subject: RE: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type >=20 > I don't have a problem with the proposal to specify a simpler=20 > interface type for the use cases described. It seems=20 > preferable for a vendor to be able to say that it fully=20 > implements a particular interface type rather than having to=20 > say that it implements an interface type but lacking features=20 > a,b,c etc. >=20 > There are many radio systems that perform routing below IP=20 > and provide a full broadcast-based abstraction, but for which=20 > the neighbor costs are unequal and it would be nice to be=20 > able to represent them that way in OSPF. Moreover, people=20 > are now designing radio to router protocols to allow these=20 > unequal costs to be dynamic and automatically computed.=20 >=20 > It might be nice to define broadcast-oriented interface types=20 > progressively as follows: >=20 > 1) existing broadcast interface for equal-cost neighbors > 2) the proposed hybrid interface for full mesh broadcast=20 > links with unequal neighbor costs > 3) correct the DR election and flooding behavior for links=20 > that may be partial mesh >=20 > The above could all be separate interface types, and 2) and=20 > 3) could each be supplemented by additional capabilities: > - optional radio-to-router control protocol to determine the=20 > unequal neighbor costs or router priorities automatically > - overhead reduction techniques such as differential hellos=20 > or partial topology reporting >=20 > Tom > = From sriganesh.kini@ericsson.com Tue Mar 29 08:48:27 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A6D3A6812 for ; Tue, 29 Mar 2011 08:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.043 X-Spam-Level: X-Spam-Status: No, score=-6.043 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajIwVnDkLFjm for ; Tue, 29 Mar 2011 08:48:26 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id BE4163A67E4 for ; Tue, 29 Mar 2011 08:48:26 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2TFo485006696 for ; Tue, 29 Mar 2011 10:50:05 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 29 Mar 2011 11:49:58 -0400 From: Sriganesh Kini To: "ospf@ietf.org" Date: Tue, 29 Mar 2011 11:49:56 -0400 Thread-Topic: FYI on draft-kini-ospf-fast-notification-01 Thread-Index: AcvuKPPJkEhNbNnJQRC0V7XzEph3oQ== Message-ID: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9BEUSAACMS0703e_" MIME-Version: 1.0 Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 15:48:28 -0000 --_000_5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9BEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just an FYI to the list This draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 = was presented at the OSPF WG mtg today. Thanks for the comments/questions at the mic. We will submit a new version = addressing the comments. Note that the other drafts related to Fast Notification (FN) are draft-lu-f= n-transport and draft-lu-fast-notification-framework. These were presented = in RTGWG. Thanks - Sri --_000_5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9BEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just an F= YI to the=20 list
 
This draf= t http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 was=20 presented at the OSPF WG mtg today.
 
Thanks fo= r the=20 comments/questions at the mic. We will submit a new version addressing the= =20 comments.
 
Note that= the other=20 drafts related to Fast Notification (FN) are draft-lu-fn-transport and=20 draft-lu-fast-notification-framework. These were presented in=20 RTGWG.
 
Thanks

- Sri=20

--_000_5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9BEUSAACMS0703e_-- From gregimirsky@gmail.com Tue Mar 29 17:44:24 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DCA3A6AF3 for ; Tue, 29 Mar 2011 17:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqhoA6nqT-wh for ; Tue, 29 Mar 2011 17:44:23 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E9CAD3A6AF8 for ; Tue, 29 Mar 2011 17:44:22 -0700 (PDT) Received: by vws12 with SMTP id 12so726781vws.31 for ; Tue, 29 Mar 2011 17:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7Fdl94DqHaX8pLgKzwbQl2D1b0bv7vLmD5JKln9z2HI=; b=DsdB0sqQ49+OwwbMAJh1SM/gKZOkLI4y2kBj017t6BpACoMkWEA1kuhcbAlsArX5F/ UZ/jPJnK5s9nfgTbNhowzJ3HAeeHrTyCyixeoxsWy7/EyHttw7KoqYvzdW3qxTHM+mo8 EGWfsbMqaXH8yMUpnMj+yob4okimwpNFo5YPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NFf3uY929GH/8NbAWV1hl81S6xoaRMx8tPoxfLKSXg/kVbL6Mc4bmdHJrvbXcXv6AJ yPB6l0cL2GOYta0y+Sh4llT+NBCCxbSU2UWsiORy0eRbu/a9dqfeXMJaj9wm7RPscDmD XqDhvEe0rmERDjEISJqlGhkHTqHv/QmjcHjY0= MIME-Version: 1.0 Received: by 10.52.179.138 with SMTP id dg10mr692041vdc.55.1301445959943; Tue, 29 Mar 2011 17:45:59 -0700 (PDT) Received: by 10.52.161.198 with HTTP; Tue, 29 Mar 2011 17:45:59 -0700 (PDT) In-Reply-To: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> References: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> Date: Tue, 29 Mar 2011 17:45:59 -0700 Message-ID: From: Greg Mirsky To: Sriganesh Kini , Wenhu Lu , albert.tian@ericsson.com Content-Type: multipart/alternative; boundary=bcaec5014c85230799049fa88050 Cc: "ospf@ietf.org" Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 00:44:24 -0000 --bcaec5014c85230799049fa88050 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, please kindly consider my comments and questions below (though some could be duplicates of already received): - section 4.3 Fast Flooding has reliability as first requirement. I've noticed that Section 4 Operation doesn't list Auto-discovery or Registration as part of Fast Failure Notification mechanism. Is it assumed that an IGP will build the list of addressees, participants of the Fast Notification? - how would node(s) that detected a failure would achieve reliable transport of notifications? - if full set of destinations is not known what indicates that notification reached all participants? - when requiring reliability of notification transport you consider "notification received" or "notification processed" - section 5.2 I believe that in the scenario you present not only node B will flood notifications, but node A will flood them as well. That would not change convergence time if only to improve it in some scenarios but it might be worth to mention that notifications will be generated by both ends of a failed link. Regards, Greg On Tue, Mar 29, 2011 at 8:49 AM, Sriganesh Kini wrote: > Just an FYI to the list > > This draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 was > presented at the OSPF WG mtg today. > > Thanks for the comments/questions at the mic. We will submit a new version > addressing the comments. > > Note that the other drafts related to Fast Notification (FN) are > draft-lu-fn-transport and draft-lu-fast-notification-framework. These were > presented in RTGWG. > > Thanks > > - Sri > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > --bcaec5014c85230799049fa88050 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,
please kindly consider my comments and questions below (th= ough some could be duplicates of already received):
  • section 4.3 = Fast Flooding has reliability as first requirement. I've noticed that S= ection 4 Operation doesn't list Auto-discovery or Registration as part = of Fast Failure Notification mechanism. Is it assumed that an IGP will buil= d the list of addressees, participants of the Fast Notification?
  • how would node(s) that detected a failure would achieve reliable t= ransport of notifications?
  • if full set of destinations is not = known what indicates that notification reached all participants?
  • when requiring reliability of notification transport you consider "= ;notification received" or "notification processed"
  • = section 5.2 I believe that in the scenario you present not only node B will= flood notifications, but node A will flood them as well. That would not ch= ange convergence time if only to improve it in some scenarios but it might = be worth to mention that notifications will be generated by both ends of a = failed link.

Regards,
Greg

On Tue, Mar 29,= 2011 at 8:49 AM, Sriganesh Kini <sriganesh.kini@ericsson.com> wrote:
Just an FYI to the=20 list
=A0
=A0
Thanks for the=20 comments/questions at the mic. We will submit a new version addressing the= =20 comments.
=A0
Note that the other=20 drafts related to Fast Notification (FN) are draft-lu-fn-transport and=20 draft-lu-fast-notification-framework. These were presented in=20 RTGWG.
=A0
Thanks

- Sri= =20


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


--bcaec5014c85230799049fa88050-- From sriganeshkini@gmail.com Tue Mar 29 23:16:07 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A81A3A6A9A for ; Tue, 29 Mar 2011 23:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN36+7oXjT-S for ; Tue, 29 Mar 2011 23:16:05 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 56E933A6A87 for ; Tue, 29 Mar 2011 23:16:05 -0700 (PDT) Received: by qwg5 with SMTP id 5so687426qwg.31 for ; Tue, 29 Mar 2011 23:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=p3nxr8Jsf08jNE14qSKRPvQletDqZTZIAVbDJfMxXPI=; b=cVreV7H1v4iYx1ANcnybJ3ApFNV1AhFMny3WnWzUAWarYUphM5Yy3TiJTp+qpG7Azm o2JlkR21nQ6ZtOM/os9nRRMjdEK2xZs8VyFMRADsUjFNaXS+A5cODfj9BcJBbUgZEos6 bU9+kfDZl1zw4kerE5uRPbO08f7VPSAtajEW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=WvAlznhb1tkCXk6mfW/KIbKMYv0cO2+q6sBugZCKyNdwswgLMd2O3MygGJySseGxye ODPyAx04nYHaZzBjl8UIYVUJnq/dueMg2JlvcQoL5JWn7SqxuVmfcxKV9gOqR5fPkVfZ j4RGyWhKYQqFnlmwy+dYsqzM0raI9+/B/SDpk= Received: by 10.229.1.93 with SMTP id 29mr687691qce.66.1301465863755; Tue, 29 Mar 2011 23:17:43 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.136.12 with HTTP; Tue, 29 Mar 2011 23:17:12 -0700 (PDT) In-Reply-To: References: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> From: Sriganesh Kini Date: Tue, 29 Mar 2011 23:17:12 -0700 X-Google-Sender-Auth: 3sxkXTNYuM34TnxNu9957YeRyjM Message-ID: To: Greg Mirsky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: albert.tian@ericsson.com, Wenhu Lu , "ospf@ietf.org" Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 06:16:07 -0000 inline On Tue, Mar 29, 2011 at 5:45 PM, Greg Mirsky wrote: > Dear Authors, > please kindly consider my comments and questions below (though some could= be > duplicates of already received): > > section 4.3 Fast Flooding has reliability as first requirement. I've noti= ced > that Section 4 Operation doesn't list Auto-discovery or Registration as p= art > of Fast Failure Notification mechanism. Is it assumed that an IGP will bu= ild > the list of addressees, participants of the Fast Notification? > how would node(s) that detected a failure would achieve reliable transpor= t > of notifications? This is through capability advertisement. It was in the -00 but was erroneously omitted in -01. Will be re-added. > if full set of destinations is not known what indicates that notification > reached all participants? > when requiring reliability of notification transport you consider > "notification received" or "notification processed" There is no ack for FN. Redundancy is achieved by using redundant trees. OSPF Flooding ensures consistency in the worst case. > section 5.2 I believe that in the scenario you present not only node B wi= ll > flood notifications, but node A will flood them as well. That would not > change convergence time if only to improve it in some scenarios but it mi= ght > be worth to mention that notifications will be generated by both ends of = a > failed link. That depends on the failure and its detection. It will only improve things and has been mentioned in the related drafts. > > Regards, > Greg > > On Tue, Mar 29, 2011 at 8:49 AM, Sriganesh Kini > wrote: >> >> Just an FYI to the list >> >> This draft >> http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01=A0was >> presented at the OSPF WG mtg today. >> >> Thanks for the comments/questions at the mic. We will submit a new versi= on >> addressing the comments. >> >> Note that the other drafts related to Fast Notification (FN) are >> draft-lu-fn-transport and draft-lu-fast-notification-framework. These we= re >> presented in RTGWG. >> >> Thanks >> >> - Sri >> >> _______________________________________________ >> 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 > > --=20 - Sri From manav.bhatia@alcatel-lucent.com Wed Mar 30 00:53:12 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7C03A6969 for ; Wed, 30 Mar 2011 00:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.81 X-Spam-Level: X-Spam-Status: No, score=-6.81 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KedvNDgz8jtQ for ; Wed, 30 Mar 2011 00:53:09 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 95C233A6AF5 for ; Wed, 30 Mar 2011 00:53:09 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2U7sdFL014828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2011 02:54:42 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2U7sd4Y012720 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Mar 2011 13:24:39 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 30 Mar 2011 13:24:39 +0530 From: "Bhatia, Manav (Manav)" To: Sriganesh Kini Date: Wed, 30 Mar 2011 13:24:36 +0530 Thread-Topic: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Thread-Index: AcvuKPPJkEhNbNnJQRC0V7XzEph3oQAhNhvg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF66A60@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350CFCF66A60INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "ospf@ietf.org" Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 07:53:12 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFCF66A60INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sri, This is regarding the point that i had raised yesterday - If the routers fl= ood the "LSAs" in the data plane without verifying them, then we're leaving= a hole open for DoS attacks, as any packet masquerading as a legitimate OS= PF packet will get flooded on all routers. This is different from data pack= ets flooding as these packets will be occupying the higest priority queues = in both the ingress, egress and the CPU. Second, what happens if the control packet is carrying an OSPF authenticati= on digest? Would you still flood it without verifying the contents or would= those be flooded regardless? I guess, you said that it would be the former= . If thats the case, then this is not easy to do it in the HW as you would = (i) need to parse the OSPF payload first to determine that its carrying a d= igest (ii) you would then need to verify it, which means you would be runni= ng HMAC-SHA in HW on the packet (given the Apad stuff that we have added in= RFC5709 i dont think you can easily do this in HW) (iii) once the digest i= s verified you would need to flood it out on all the valid OSPF interfaces. Cheers, Manav ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Sri= ganesh Kini Sent: Tuesday, March 29, 2011 9.20 PM To: ospf@ietf.org Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Just an FYI to the list This draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 = was presented at the OSPF WG mtg today. Thanks for the comments/questions at the mic. We will submit a new version = addressing the comments. Note that the other drafts related to Fast Notification (FN) are draft-lu-f= n-transport and draft-lu-fast-notification-framework. These were presented = in RTGWG. Thanks - Sri --_000_7C362EEF9C7896468B36C9B79200D8350CFCF66A60INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sri,
 
This is regarding the point that i had raised ye= sterday=20 - If the routers flood the "LSAs" in the data plane without verifying them,= then=20 we're leaving a hole open for DoS attacks, as any packet masquerading as a= =20 legitimate OSPF packet will get flooded on all routers. This is different f= rom=20 data packets flooding as these packets will be occupying the higest priorit= y=20 queues in both the ingress, egress and the CPU.
 
Second, what happens if the control packet is ca= rrying=20 an OSPF authentication digest? Would you still flood it without verifying t= he=20 contents or would those be flooded regardless? I guess, you said that it wo= uld=20 be the former. If thats the case, then this is not easy to do it in the HW = as=20 you would (i) need to parse the OSPF payload first to determine that its=20 carrying a digest (ii) you would then need to verify it, which means you wo= uld=20 be running HMAC-SHA in HW on the packet (given the Apad stuff that we have = added=20 in RFC5709 i dont think you can easily do this in HW) (iii) once the digest= is=20 verified you would need to flood it out on all the valid OSPF=20 interfaces.
 
Cheers,=20 Manav
From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Sriganesh=20 Kini
Sent: Tuesday, March 29, 2011 9.20 PM
To:=20 ospf@ietf.org
Subject: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Just an= FYI to the=20 list
 
This dr= aft = http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01<= /FONT> was=20 presented at the OSPF WG mtg today.
 
Thanks = for the=20 comments/questions at the mic. We will submit a new version addressing th= e=20 comments.
 
Note th= at the=20 other drafts related to Fast Notification (FN) are draft-lu-fn-transport = and=20 draft-lu-fast-notification-framework. These were presented in=20 RTGWG.
 
Thanks

- Sri=20

--_000_7C362EEF9C7896468B36C9B79200D8350CFCF66A60INBANSXCHMBSA_-- From sriganeshkini@gmail.com Wed Mar 30 02:44:11 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D823E3A6B41 for ; Wed, 30 Mar 2011 02:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFub-NFVTy37 for ; Wed, 30 Mar 2011 02:44:10 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id C69E53A6B38 for ; Wed, 30 Mar 2011 02:44:10 -0700 (PDT) Received: by qwg5 with SMTP id 5so794394qwg.31 for ; Wed, 30 Mar 2011 02:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=arQkHemHwjkVR3pul66Xkaj/fe4OrlVUMNLF0brQbtI=; b=DHg0dnS6pyYudh9I9SMHrh0NPbhAkJa580lrJ9KSImagLJTdGWSOorCFiJSWlwR2ip JYtaR8VjTHrK0lDYj/mrtCenB423xdOQfeGNrwBFZ7dklvSaVYTOUrpc4jQO6ladZX89 42dIaspr4Tc39zuKz/qJQ6W3lmGmo7htU3ktA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=Q/FvUBiWfOaThbciz5drZfktsVuo7iCkBiNnnfcIkNNFlzZkM4d8+bW31mm2Uhvxie HXPgbSyV8wrc+sfnewRd2HCH8ISTALoFkZxSbV1GoTlOXK9FwfvPqBpUot0YRpY5Y2Ej IkKsHa+D5n7pWRel81/Pqm4LTVl9BmKWh+LsY= Received: by 10.229.1.93 with SMTP id 29mr819179qce.66.1301478349102; Wed, 30 Mar 2011 02:45:49 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.136.12 with HTTP; Wed, 30 Mar 2011 02:45:19 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFCF66A60@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66A60@INBANSXCHMBSA1.in.alcatel-lucent.com> From: Sriganesh Kini Date: Wed, 30 Mar 2011 02:45:19 -0700 X-Google-Sender-Auth: y7Eke1VdR4cwASzGPzQo_zn3TME Message-ID: To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ospf@ietf.org" Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 09:44:11 -0000 Hi Manav, see inline On Wed, Mar 30, 2011 at 12:54 AM, Bhatia, Manav (Manav) wrote: > Hi Sri, > > This is regarding the point that i had raised yesterday - If the routers > flood the "LSAs" in the data plane without verifying them, then we're > leaving a hole open for DoS attacks, as any packet masquerading as a > legitimate OSPF packet will get flooded on all routers. This is different > from data packets flooding as these packets will be occupying the higest > priority queues in both the ingress, egress and the CPU. Control pkts (not restricted to FN) though given high priority, the good implementations use throttling mechanisms to prevent (D)DoS. Root-causing of related alarms is also a high priority operational procedure. > > Second, what happens if the control packet is carrying an OSPF > authentication digest? Would you still flood it without verifying the > contents or would those be flooded regardless? I guess, you said that it > would be the former. If thats the case, then this is not easy to do it in > the HW as you would (i) need to parse the OSPF payload first to determine > that its carrying a digest (ii) you would then need to verify it, which > means you would be running HMAC-SHA in HW on the packet (given the Apad > stuff that we have added in RFC5709 i dont think you can easily do this i= n > HW) (iii) once the digest is verified you would need to flood it out on a= ll > the valid OSPF interfaces. What I said is that verification before flooding is also an option we have considered (see draft-lu-fn-transport for details). In our prototyping experience the overhead of verifying auth in HW was not much. However we do recognize that this may not be true with all HW and all auth methods. It may introduce more delays in FN delivery in some architectures and implementations. So forwarding without verifying could get better convergence times at the expense of the invalid FN packet reaching more nodes. If a platform is capable of verifying without introducing a lot of delay then it should definitely do it and such a platform can mitigate the problem in the network where other platforms may not verifying before forwarding. > > Cheers, Manav > > ________________________________ > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of > Sriganesh Kini > Sent: Tuesday, March 29, 2011 9.20 PM > To: ospf@ietf.org > Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01 > > Just an FYI to the list > > This draft > http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01=A0was > presented at the OSPF WG mtg today. > > Thanks for the comments/questions at the mic. We will submit a new versio= n > addressing the comments. > > Note that the other drafts related to Fast Notification (FN) are > draft-lu-fn-transport and draft-lu-fast-notification-framework. These wer= e > presented in RTGWG. > > Thanks > > - Sri > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > --=20 - Sri From manav.bhatia@alcatel-lucent.com Wed Mar 30 05:03:21 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D4228C13D for ; Wed, 30 Mar 2011 05:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.806 X-Spam-Level: X-Spam-Status: No, score=-6.806 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BMJCeLDMent for ; Wed, 30 Mar 2011 05:03:20 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 5688F28C118 for ; Wed, 30 Mar 2011 05:03:20 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p2UC4rZf013116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2011 07:04:56 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2UC4qrw000536 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Mar 2011 17:34:52 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 30 Mar 2011 17:34:52 +0530 From: "Bhatia, Manav (Manav)" To: Wenhu Lu , Sriganesh Kini Date: Wed, 30 Mar 2011 17:34:53 +0530 Thread-Topic: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Thread-Index: AcvuKPPJkEhNbNnJQRC0V7XzEph3oQAhNhvgAAjMLrAAAFgioA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF66AF9@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66A60@INBANSXCHMBSA1.in.alcatel-lucent.com> <8249B703AE8442429AF89B86E8206AA26EF567C38D@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <8249B703AE8442429AF89B86E8206AA26EF567C38D@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350CFCF66AF9INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "ospf@ietf.org" Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:03:21 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFCF66AF9INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Wenhu, I never asserted they would - If you claim to do auth verification in HW th= en you would presumably take care of this as well. I'm saying that either ways you have an issue. Cheers, Manav ________________________________ From: Wenhu Lu [mailto:wenhu.lu@ericsson.com] Sent: Wednesday, March 30, 2011 5.31 PM To: Bhatia, Manav (Manav); Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Manav, How would the data-plane auth verification prevent such DoS attacks? Any replayed packets will go through. Thanks, -wenhu ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bha= tia, Manav (Manav) Sent: Wednesday, March 30, 2011 12:55 AM To: Sriganesh Kini Cc: ospf@ietf.org Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Sri, This is regarding the point that i had raised yesterday - If the routers fl= ood the "LSAs" in the data plane without verifying them, then we're leaving= a hole open for DoS attacks, as any packet masquerading as a legitimate OS= PF packet will get flooded on all routers. This is different from data pack= ets flooding as these packets will be occupying the higest priority queues = in both the ingress, egress and the CPU. Second, what happens if the control packet is carrying an OSPF authenticati= on digest? Would you still flood it without verifying the contents or would= those be flooded regardless? I guess, you said that it would be the former= . If thats the case, then this is not easy to do it in the HW as you would = (i) need to parse the OSPF payload first to determine that its carrying a d= igest (ii) you would then need to verify it, which means you would be runni= ng HMAC-SHA in HW on the packet (given the Apad stuff that we have added in= RFC5709 i dont think you can easily do this in HW) (iii) once the digest i= s verified you would need to flood it out on all the valid OSPF interfaces. Cheers, Manav ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Sri= ganesh Kini Sent: Tuesday, March 29, 2011 9.20 PM To: ospf@ietf.org Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Just an FYI to the list This draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 = was presented at the OSPF WG mtg today. Thanks for the comments/questions at the mic. We will submit a new version = addressing the comments. Note that the other drafts related to Fast Notification (FN) are draft-lu-f= n-transport and draft-lu-fast-notification-framework. These were presented = in RTGWG. Thanks - Sri --_000_7C362EEF9C7896468B36C9B79200D8350CFCF66AF9INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Wenhu,
 
I never asserted they would - If you claim to do a= uth=20 verification in HW then you would presumably take care of this as=20 well.
 
I'm saying that either ways you have an=20 issue.
 
Cheers, Manav

From: Wenhu Lu [mailto:wenhu.lu@erics= son.com]=20
Sent: Wednesday, March 30, 2011 5.31 PM
To: Bhatia, = Manav=20 (Manav); Sriganesh Kini
Cc: ospf@ietf.org
Subject: RE= :=20 [OSPF] FYI on draft-kini-ospf-fast-notification-01

Hi=20 Manav,
How=20 would the data-plane auth verification prevent such DoS=20 attacks?
Any=20 replayed packets will go through.
 
Thanks,
-wenhu

From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Bhatia, Manav=20 (Manav)
Sent: Wednesday, March 30, 2011 12:55 AM
To:= =20 Sriganesh Kini
Cc: ospf@ietf.org
Subject: Re: [OSPF] = FYI=20 on draft-kini-ospf-fast-notification-01

<= SPAN=20 class=3D335534007-30032011>Hi Sri,
<= SPAN=20 class=3D335534007-30032011> 
<= SPAN=20 class=3D335534007-30032011>This is regarding the point that i had raised= =20 yesterday - If the routers flood the "LSAs" in the data plane without=20 verifying them, then we're leaving a hole open for DoS attacks, as any pa= cket=20 masquerading as a legitimate OSPF packet will get flooded on all routers.= This=20 is different from data packets flooding as these packets will be occupyin= g the=20 higest priority queues in both the ingress, egress and the=20 CPU.
<= SPAN=20 class=3D335534007-30032011> 
<= SPAN=20 class=3D335534007-30032011>Second, what happens if the control packet is= =20 carrying an OSPF authentication digest? Would you still flood it without= =20 verifying the contents or would those be flooded regardless? I guess, you= said=20 that it would be the former. If thats the case, then this is not easy to = do it=20 in the HW as you would (i) need to parse the OSPF payload first to determ= ine=20 that its carrying a digest (ii) you would then need to verify it, which m= eans=20 you would be running HMAC-SHA in HW on the packet (given the Apad stuff t= hat=20 we have added in RFC5709 i dont think you can easily do this in HW) (iii)= once=20 the digest is verified you would need to flood it out on all the valid OS= PF=20 interfaces.
 
Cheers,=20 Manav
From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Sriganesh=20 Kini
Sent: Tuesday, March 29, 2011 9.20 PM
To:=20 ospf@ietf.org
Subject: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Just = an FYI to=20 the list
 
This = draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-0= 1 was=20 presented at the OSPF WG mtg today.
 
Thank= s for the=20 comments/questions at the mic. We will submit a new version addressing = the=20 comments.
 
Note = that the=20 other drafts related to Fast Notification (FN) are draft-lu-fn-transpor= t and=20 draft-lu-fast-notification-framework. These were presented in=20 RTGWG.
 
Thanks

- Sri=20

--_000_7C362EEF9C7896468B36C9B79200D8350CFCF66AF9INBANSXCHMBSA_-- From wenhu.lu@ericsson.com Wed Mar 30 05:06:22 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D700B28C13D for ; Wed, 30 Mar 2011 05:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsdKCfUa3SKz for ; Wed, 30 Mar 2011 05:06:21 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id B48A53A6B46 for ; Wed, 30 Mar 2011 05:06:18 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2UC7rIW010570; Wed, 30 Mar 2011 07:07:56 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 30 Mar 2011 08:07:52 -0400 From: Wenhu Lu To: "Bhatia, Manav (Manav)" , Sriganesh Kini Date: Wed, 30 Mar 2011 08:07:50 -0400 Thread-Topic: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Thread-Index: AcvuKPPJkEhNbNnJQRC0V7XzEph3oQAhNhvgAAlNsgA= Message-ID: <8249B703AE8442429AF89B86E8206AA26EF567C390@EUSAACMS0703.eamcs.ericsson.se> References: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66A60@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFCF66A60@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8249B703AE8442429AF89B86E8206AA26EF567C390EUSAACMS0703e_" MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:06:22 -0000 --_000_8249B703AE8442429AF89B86E8206AA26EF567C390EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Manav, How would the data-plane auth verification prevent such DoS attacks? Any replayed packets will go through. Thanks, -wenhu ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bha= tia, Manav (Manav) Sent: Wednesday, March 30, 2011 12:55 AM To: Sriganesh Kini Cc: ospf@ietf.org Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Sri, This is regarding the point that i had raised yesterday - If the routers fl= ood the "LSAs" in the data plane without verifying them, then we're leaving= a hole open for DoS attacks, as any packet masquerading as a legitimate OS= PF packet will get flooded on all routers. This is different from data pack= ets flooding as these packets will be occupying the higest priority queues = in both the ingress, egress and the CPU. Second, what happens if the control packet is carrying an OSPF authenticati= on digest? Would you still flood it without verifying the contents or would= those be flooded regardless? I guess, you said that it would be the former= . If thats the case, then this is not easy to do it in the HW as you would = (i) need to parse the OSPF payload first to determine that its carrying a d= igest (ii) you would then need to verify it, which means you would be runni= ng HMAC-SHA in HW on the packet (given the Apad stuff that we have added in= RFC5709 i dont think you can easily do this in HW) (iii) once the digest i= s verified you would need to flood it out on all the valid OSPF interfaces. Cheers, Manav ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Sri= ganesh Kini Sent: Tuesday, March 29, 2011 9.20 PM To: ospf@ietf.org Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Just an FYI to the list This draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 = was presented at the OSPF WG mtg today. Thanks for the comments/questions at the mic. We will submit a new version = addressing the comments. Note that the other drafts related to Fast Notification (FN) are draft-lu-f= n-transport and draft-lu-fast-notification-framework. These were presented = in RTGWG. Thanks - Sri --_000_8249B703AE8442429AF89B86E8206AA26EF567C390EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Manav,
How=20 would the data-plane auth verification prevent such DoS=20 attacks?
Any=20 replayed packets will go through.
 
Thanks,
-wenhu

From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Bhatia, Manav=20 (Manav)
Sent: Wednesday, March 30, 2011 12:55 AM
To:=20 Sriganesh Kini
Cc: ospf@ietf.org
Subject: Re: [OSPF] FY= I on=20 draft-kini-ospf-fast-notification-01

Hi Sri,
 
This is regarding the point that i had raised ye= sterday=20 - If the routers flood the "LSAs" in the data plane without verifying them,= then=20 we're leaving a hole open for DoS attacks, as any packet masquerading as a= =20 legitimate OSPF packet will get flooded on all routers. This is different f= rom=20 data packets flooding as these packets will be occupying the higest priorit= y=20 queues in both the ingress, egress and the CPU.
 
Second, what happens if the control packet is ca= rrying=20 an OSPF authentication digest? Would you still flood it without verifying t= he=20 contents or would those be flooded regardless? I guess, you said that it wo= uld=20 be the former. If thats the case, then this is not easy to do it in the HW = as=20 you would (i) need to parse the OSPF payload first to determine that its=20 carrying a digest (ii) you would then need to verify it, which means you wo= uld=20 be running HMAC-SHA in HW on the packet (given the Apad stuff that we have = added=20 in RFC5709 i dont think you can easily do this in HW) (iii) once the digest= is=20 verified you would need to flood it out on all the valid OSPF=20 interfaces.
 
Cheers,=20 Manav
From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Sriganesh=20 Kini
Sent: Tuesday, March 29, 2011 9.20 PM
To:=20 ospf@ietf.org
Subject: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Just an= FYI to the=20 list
 
This dr= aft = http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01<= /FONT> was=20 presented at the OSPF WG mtg today.
 
Thanks = for the=20 comments/questions at the mic. We will submit a new version addressing th= e=20 comments.
 
Note th= at the=20 other drafts related to Fast Notification (FN) are draft-lu-fn-transport = and=20 draft-lu-fast-notification-framework. These were presented in=20 RTGWG.
 
Thanks

- Sri=20

--_000_8249B703AE8442429AF89B86E8206AA26EF567C390EUSAACMS0703e_-- From manav.bhatia@alcatel-lucent.com Wed Mar 30 05:14:46 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B15128C108 for ; Wed, 30 Mar 2011 05:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.804 X-Spam-Level: X-Spam-Status: No, score=-6.804 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yfoZ7VMHCso for ; Wed, 30 Mar 2011 05:14:45 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 7512828C0E4 for ; Wed, 30 Mar 2011 05:14:45 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p2UCGIeI002547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2011 07:16:21 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2UCGIDI001192 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Mar 2011 17:46:18 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 30 Mar 2011 17:46:18 +0530 From: "Bhatia, Manav (Manav)" To: Sriganesh Kini Date: Wed, 30 Mar 2011 17:46:21 +0530 Thread-Topic: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Thread-Index: Acvuv0VZsl5qtNW2TfSt6n2ilOhIWQAEjczA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF66AFE@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66A60@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "ospf@ietf.org" Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:14:46 -0000 Hi Sri, > > flood the "LSAs" in the data plane without verifying them,=20 > then we're > > leaving a hole open for DoS attacks, as any packet masquerading as a > > legitimate OSPF packet will get flooded on all routers.=20 > This is different > > from data packets flooding as these packets will be=20 > occupying the higest > > priority queues in both the ingress, egress and the CPU. >=20 > Control pkts (not restricted to FN) though given high priority, the > good implementations use throttling mechanisms to prevent (D)DoS. > Root-causing of related alarms is also a high priority operational > procedure. I agree that all implementations rate limit all kinds of traffic, but you w= ould concede that limiting is much less aggressive for network control (NC)= packets. This also means that a bunch of illegitimate NC packets will actu= ally affect the genuine NC traffic - so you could on certain platforms see = 10ms BFD flaps because theres a flood of data-plane forwarded LSAs.=20 Most QoS scheduling algorithms would drain the NC queue first before gettin= g to the other (BE, AF, etc) queues. While the algorithm could change (stri= ct scheduling, WFQ, etc) the end result would still be the same, where NC p= ackets would *affect* other queues/traffic. Thus my point is that we should= be extremely circumspect with any proposal that unabashedly floods control= traffic. >=20 > > > > Second, what happens if the control packet is carrying an OSPF > > authentication digest? Would you still flood it without=20 > verifying the > > contents or would those be flooded regardless? I guess, you=20 > said that it > > would be the former. If thats the case, then this is not=20 > easy to do it in > > the HW as you would (i) need to parse the OSPF payload=20 > first to determine > > that its carrying a digest (ii) you would then need to=20 > verify it, which > > means you would be running HMAC-SHA in HW on the packet=20 > (given the Apad > > stuff that we have added in RFC5709 i dont think you can=20 > easily do this in > > HW) (iii) once the digest is verified you would need to=20 > flood it out on all > > the valid OSPF interfaces. >=20 > What I said is that verification before flooding is also an option we > have considered (see draft-lu-fn-transport for details). In our > prototyping experience the overhead of verifying auth in HW was not > much. However we do recognize that this may not be true with all HW > and all auth methods. It may introduce more delays in FN delivery in I can say with a very high degree of confidence that most, if not all, ASIC= based silicons will not be able to do the HMAC-SHA kind of authentication = verification that has been proposed in RFC 5310, RFC 5709, RFC 4822 and sco= res of other IETF routing drafts on BFD, LDP, etc. > some architectures and implementations. So forwarding without > verifying could get better convergence times at the expense of the > invalid FN packet reaching more nodes.=20 .. and potentially flapping BFD and other control plane protocols. > If a platform is capable of > verifying without introducing a lot of delay then it should definitely > do it and such a platform can mitigate the problem in the network > where other platforms may not verifying before forwarding. Yes, but that cant happen today. Cheers, Manav= From wenhu.lu@ericsson.com Wed Mar 30 05:19:51 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715CD28C146 for ; Wed, 30 Mar 2011 05:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA4mp2SpIe3K for ; Wed, 30 Mar 2011 05:19:50 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 0E8E028C17F for ; Wed, 30 Mar 2011 05:19:49 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p2UCLRse028550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Mar 2011 07:21:28 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 30 Mar 2011 08:21:27 -0400 From: Wenhu Lu To: "Bhatia, Manav (Manav)" , Sriganesh Kini Date: Wed, 30 Mar 2011 08:21:26 -0400 Thread-Topic: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Thread-Index: AcvuKPPJkEhNbNnJQRC0V7XzEph3oQAhNhvgAAjMLrAAAFgioAAANE8w Message-ID: <8249B703AE8442429AF89B86E8206AA26EF567C39D@EUSAACMS0703.eamcs.ericsson.se> References: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66A60@INBANSXCHMBSA1.in.alcatel-lucent.com> <8249B703AE8442429AF89B86E8206AA26EF567C38D@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66AF9@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFCF66AF9@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8249B703AE8442429AF89B86E8206AA26EF567C39DEUSAACMS0703e_" MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:19:51 -0000 --_000_8249B703AE8442429AF89B86E8206AA26EF567C39DEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Manav, If I read it correctly, your original message said there would be a hole if= we don't do verification in data plane. Now you are saying you never asser= ted it would, I'm confused. As Sri mentioned, the rate limiting should solve the problem easily. Thanks, -wenhu ________________________________ From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Wednesday, March 30, 2011 5:05 AM To: Wenhu Lu; Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Wenhu, I never asserted they would - If you claim to do auth verification in HW th= en you would presumably take care of this as well. I'm saying that either ways you have an issue. Cheers, Manav ________________________________ From: Wenhu Lu [mailto:wenhu.lu@ericsson.com] Sent: Wednesday, March 30, 2011 5.31 PM To: Bhatia, Manav (Manav); Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Manav, How would the data-plane auth verification prevent such DoS attacks? Any replayed packets will go through. Thanks, -wenhu ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bha= tia, Manav (Manav) Sent: Wednesday, March 30, 2011 12:55 AM To: Sriganesh Kini Cc: ospf@ietf.org Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Sri, This is regarding the point that i had raised yesterday - If the routers fl= ood the "LSAs" in the data plane without verifying them, then we're leaving= a hole open for DoS attacks, as any packet masquerading as a legitimate OS= PF packet will get flooded on all routers. This is different from data pack= ets flooding as these packets will be occupying the higest priority queues = in both the ingress, egress and the CPU. Second, what happens if the control packet is carrying an OSPF authenticati= on digest? Would you still flood it without verifying the contents or would= those be flooded regardless? I guess, you said that it would be the former= . If thats the case, then this is not easy to do it in the HW as you would = (i) need to parse the OSPF payload first to determine that its carrying a d= igest (ii) you would then need to verify it, which means you would be runni= ng HMAC-SHA in HW on the packet (given the Apad stuff that we have added in= RFC5709 i dont think you can easily do this in HW) (iii) once the digest i= s verified you would need to flood it out on all the valid OSPF interfaces. Cheers, Manav ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Sri= ganesh Kini Sent: Tuesday, March 29, 2011 9.20 PM To: ospf@ietf.org Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Just an FYI to the list This draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 = was presented at the OSPF WG mtg today. Thanks for the comments/questions at the mic. We will submit a new version = addressing the comments. Note that the other drafts related to Fast Notification (FN) are draft-lu-f= n-transport and draft-lu-fast-notification-framework. These were presented = in RTGWG. Thanks - Sri --_000_8249B703AE8442429AF89B86E8206AA26EF567C39DEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Manav,
If I=20 read it correctly, your original message said there would be a hole if we d= on't=20 do verification in data plane. Now you are saying you never asserted i= t=20 would, I'm confused.
As Sri=20 mentioned, the rate limiting should solve the problem=20 easily.
 
Thanks,
-wenhu

From: Bhatia, Manav (Manav)=20 [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Wednesday, March = 30,=20 2011 5:05 AM
To: Wenhu Lu; Sriganesh Kini
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi Wenhu,
 
I never asserted they would - If you claim to do a= uth=20 verification in HW then you would presumably take care of this as=20 well.
 
I'm saying that either ways you have an=20 issue.
 
Cheers, Manav

From: Wenhu Lu [mailto:wenhu.lu@erics= son.com]=20
Sent: Wednesday, March 30, 2011 5.31 PM
To: Bhatia, = Manav=20 (Manav); Sriganesh Kini
Cc: ospf@ietf.org
Subject: RE= :=20 [OSPF] FYI on draft-kini-ospf-fast-notification-01

Hi=20 Manav,
How=20 would the data-plane auth verification prevent such DoS=20 attacks?
Any=20 replayed packets will go through.
 
Thanks,
-wenhu

From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Bhatia, Manav=20 (Manav)
Sent: Wednesday, March 30, 2011 12:55 AM
To:= =20 Sriganesh Kini
Cc: ospf@ietf.org
Subject: Re: [OSPF] = FYI=20 on draft-kini-ospf-fast-notification-01

<= SPAN=20 class=3D335534007-30032011>Hi Sri,
<= SPAN=20 class=3D335534007-30032011> 
<= SPAN=20 class=3D335534007-30032011>This is regarding the point that i had raised= =20 yesterday - If the routers flood the "LSAs" in the data plane without=20 verifying them, then we're leaving a hole open for DoS attacks, as any pa= cket=20 masquerading as a legitimate OSPF packet will get flooded on all routers.= This=20 is different from data packets flooding as these packets will be occupyin= g the=20 higest priority queues in both the ingress, egress and the=20 CPU.
<= SPAN=20 class=3D335534007-30032011> 
<= SPAN=20 class=3D335534007-30032011>Second, what happens if the control packet is= =20 carrying an OSPF authentication digest? Would you still flood it without= =20 verifying the contents or would those be flooded regardless? I guess, you= said=20 that it would be the former. If thats the case, then this is not easy to = do it=20 in the HW as you would (i) need to parse the OSPF payload first to determ= ine=20 that its carrying a digest (ii) you would then need to verify it, which m= eans=20 you would be running HMAC-SHA in HW on the packet (given the Apad stuff t= hat=20 we have added in RFC5709 i dont think you can easily do this in HW) (iii)= once=20 the digest is verified you would need to flood it out on all the valid OS= PF=20 interfaces.
 
Cheers,=20 Manav
From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Sriganesh=20 Kini
Sent: Tuesday, March 29, 2011 9.20 PM
To:=20 ospf@ietf.org
Subject: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Just = an FYI to=20 the list
 
This = draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-0= 1 was=20 presented at the OSPF WG mtg today.
 
Thank= s for the=20 comments/questions at the mic. We will submit a new version addressing = the=20 comments.
 
Note = that the=20 other drafts related to Fast Notification (FN) are draft-lu-fn-transpor= t and=20 draft-lu-fast-notification-framework. These were presented in=20 RTGWG.
 
Thanks

- Sri=20

--_000_8249B703AE8442429AF89B86E8206AA26EF567C39DEUSAACMS0703e_-- From manav.bhatia@alcatel-lucent.com Wed Mar 30 05:28:01 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54EAE28C130 for ; Wed, 30 Mar 2011 05:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.722 X-Spam-Level: X-Spam-Status: No, score=-6.722 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT8Ds4CeT97T for ; Wed, 30 Mar 2011 05:27:53 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A983C28C121 for ; Wed, 30 Mar 2011 05:27:52 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p2UCTP8J011145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2011 07:29:27 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2UCTOvJ028242 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Mar 2011 17:59:24 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 30 Mar 2011 17:59:24 +0530 From: "Bhatia, Manav (Manav)" To: Wenhu Lu , Sriganesh Kini Date: Wed, 30 Mar 2011 17:59:21 +0530 Thread-Topic: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Thread-Index: AcvuKPPJkEhNbNnJQRC0V7XzEph3oQAhNhvgAAjMLrAAAFgioAAANE8wAACXR0A= Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF66B06@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66A60@INBANSXCHMBSA1.in.alcatel-lucent.com> <8249B703AE8442429AF89B86E8206AA26EF567C38D@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66AF9@INBANSXCHMBSA1.in.alcatel-lucent.com> <8249B703AE8442429AF89B86E8206AA26EF567C39D@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <8249B703AE8442429AF89B86E8206AA26EF567C39D@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350CFCF66B06INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "ospf@ietf.org" Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:28:01 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFCF66B06INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Wenhu, I am trying to say this: If you dont do verification in HW then you leave a hole open for DoS, which= means that you MUST do verification before flooding. However, this is easi= er said than done, and its extremely complex and convoluted to do this in H= W. And this is precisely why i had said "I'm saying that either ways you have = an issue." in my last mail that you responded to. Cheers, Manav ________________________________ From: Wenhu Lu [mailto:wenhu.lu@ericsson.com] Sent: Wednesday, March 30, 2011 5.51 PM To: Bhatia, Manav (Manav); Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Manav, If I read it correctly, your original message said there would be a hole if= we don't do verification in data plane. Now you are saying you never asser= ted it would, I'm confused. As Sri mentioned, the rate limiting should solve the problem easily. Thanks, -wenhu ________________________________ From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Wednesday, March 30, 2011 5:05 AM To: Wenhu Lu; Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Wenhu, I never asserted they would - If you claim to do auth verification in HW th= en you would presumably take care of this as well. I'm saying that either ways you have an issue. Cheers, Manav ________________________________ From: Wenhu Lu [mailto:wenhu.lu@ericsson.com] Sent: Wednesday, March 30, 2011 5.31 PM To: Bhatia, Manav (Manav); Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Manav, How would the data-plane auth verification prevent such DoS attacks? Any replayed packets will go through. Thanks, -wenhu ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bha= tia, Manav (Manav) Sent: Wednesday, March 30, 2011 12:55 AM To: Sriganesh Kini Cc: ospf@ietf.org Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Sri, This is regarding the point that i had raised yesterday - If the routers fl= ood the "LSAs" in the data plane without verifying them, then we're leaving= a hole open for DoS attacks, as any packet masquerading as a legitimate OS= PF packet will get flooded on all routers. This is different from data pack= ets flooding as these packets will be occupying the higest priority queues = in both the ingress, egress and the CPU. Second, what happens if the control packet is carrying an OSPF authenticati= on digest? Would you still flood it without verifying the contents or would= those be flooded regardless? I guess, you said that it would be the former= . If thats the case, then this is not easy to do it in the HW as you would = (i) need to parse the OSPF payload first to determine that its carrying a d= igest (ii) you would then need to verify it, which means you would be runni= ng HMAC-SHA in HW on the packet (given the Apad stuff that we have added in= RFC5709 i dont think you can easily do this in HW) (iii) once the digest i= s verified you would need to flood it out on all the valid OSPF interfaces. Cheers, Manav ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Sri= ganesh Kini Sent: Tuesday, March 29, 2011 9.20 PM To: ospf@ietf.org Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Just an FYI to the list This draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 = was presented at the OSPF WG mtg today. Thanks for the comments/questions at the mic. We will submit a new version = addressing the comments. Note that the other drafts related to Fast Notification (FN) are draft-lu-f= n-transport and draft-lu-fast-notification-framework. These were presented = in RTGWG. Thanks - Sri --_000_7C362EEF9C7896468B36C9B79200D8350CFCF66B06INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Wenhu,
 
I am trying to say this:
 
If you dont do verification in HW then you leave a= hole=20 open for DoS, which means that you MUST do verification before flooding.=20 However, this is easier said than done, and its extremely complex and convo= luted=20 to do this in HW.
 
And this is precisely why i had said "I'm = saying that=20 either ways you have an issue." in my last mail that you resp= onded=20 to.
 
Cheers, Manav
From: Wenhu Lu [mailto:wenhu.lu@erics= son.com]=20
Sent: Wednesday, March 30, 2011 5.51 PM
To: Bhatia, = Manav=20 (Manav); Sriganesh Kini
Cc: ospf@ietf.org
Subject: RE= :=20 [OSPF] FYI on draft-kini-ospf-fast-notification-01

Hi=20 Manav,
If I=20 read it correctly, your original message said there would be a hole if we= =20 don't do verification in data plane. Now you are saying you never=20 asserted it would, I'm confused.
As=20 Sri mentioned, the rate limiting should solve the problem=20 easily.
 
Thanks,
-wenhu

From: Bhatia, Manav (Manav)=20 [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Wednesday, Marc= h 30,=20 2011 5:05 AM
To: Wenhu Lu; Sriganesh Kini
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi Wenhu,
 
I never asserted they would - If you claim to do= auth=20 verification in HW then you would presumably take care of this as=20 well.
 
I'm saying that either ways you have an=20 issue.
 
Cheers, Manav

From: Wenhu Lu=20 [mailto:wenhu.lu@ericsson.com]
Sent: Wednesday, March 30, 20= 11=20 5.31 PM
To: Bhatia, Manav (Manav); Sriganesh Kini
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi=20 Manav,
How would the data-plane auth verification prevent such DoS=20 attacks?
Any replayed packets will go through.
 
Thanks,
-wenhu

From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Bhatia, Manav=20 (Manav)
Sent: Wednesday, March 30, 2011 12:55 AM
To:=20 Sriganesh Kini
Cc: ospf@ietf.org
Subject: Re: [OSPF= ] FYI=20 on draft-kini-ospf-fast-notification-01

Hi Sri,
 
This is regarding the point that i had raise= d=20 yesterday - If the routers flood the "LSAs" in the data plane without=20 verifying them, then we're leaving a hole open for DoS attacks, as any= =20 packet masquerading as a legitimate OSPF packet will get flooded on all= =20 routers. This is different from data packets flooding as these packets = will=20 be occupying the higest priority queues in both the ingress, egress and= the=20 CPU.
 
Second, what happens if the control packet i= s=20 carrying an OSPF authentication digest? Would you still flood it withou= t=20 verifying the contents or would those be flooded regardless? I guess, y= ou=20 said that it would be the former. If thats the case, then this is not e= asy=20 to do it in the HW as you would (i) need to parse the OSPF payload firs= t to=20 determine that its carrying a digest (ii) you would then need to verify= it,=20 which means you would be running HMAC-SHA in HW on the packet (given th= e=20 Apad stuff that we have added in RFC5709 i dont think you can easily do= this=20 in HW) (iii) once the digest is verified you would need to flood it out= on=20 all the valid OSPF interfaces.
 
Cheers,= =20 Manav
From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Sriganesh=20 Kini
Sent: Tuesday, March 29, 2011 9.20 PM
To:=20 ospf@ietf.org
Subject: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Jus= t an FYI to=20 the list
 
Thi= s draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification= -01 was=20 presented at the OSPF WG mtg today.
 
Tha= nks for the=20 comments/questions at the mic. We will submit a new version addressin= g the=20 comments.
 
Not= e that the=20 other drafts related to Fast Notification (FN) are draft-lu-fn-transp= ort=20 and draft-lu-fast-notification-framework. These were presented in=20 RTGWG.
 
Thanks

- Sri= =20

--_000_7C362EEF9C7896468B36C9B79200D8350CFCF66B06INBANSXCHMBSA_-- From wenhu.lu@ericsson.com Wed Mar 30 06:09:24 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F223A6781 for ; Wed, 30 Mar 2011 06:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKMPRvLL8mLU for ; Wed, 30 Mar 2011 06:09:22 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 384743A67CC for ; Wed, 30 Mar 2011 06:09:22 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2UDAmCL018055; Wed, 30 Mar 2011 08:10:56 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 30 Mar 2011 09:10:55 -0400 From: Wenhu Lu To: "Bhatia, Manav (Manav)" , Sriganesh Kini Date: Wed, 30 Mar 2011 09:10:53 -0400 Thread-Topic: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Thread-Index: AcvuKPPJkEhNbNnJQRC0V7XzEph3oQAhNhvgAAjMLrAAAFgioAAANE8wAACXR0AAAP3B4A== Message-ID: <8249B703AE8442429AF89B86E8206AA26EF567C3D0@EUSAACMS0703.eamcs.ericsson.se> References: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66A60@INBANSXCHMBSA1.in.alcatel-lucent.com> <8249B703AE8442429AF89B86E8206AA26EF567C38D@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66AF9@INBANSXCHMBSA1.in.alcatel-lucent.com> <8249B703AE8442429AF89B86E8206AA26EF567C39D@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66B06@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFCF66B06@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8249B703AE8442429AF89B86E8206AA26EF567C3D0EUSAACMS0703e_" MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 13:09:24 -0000 --_000_8249B703AE8442429AF89B86E8206AA26EF567C3D0EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Manav, Verification in HW would mean more than auth check. One will have to move s= eq number check and lot of ospf logic into hardware, which as you said is e= xtremely complex. We tried to avoid this. As for the said DoS attacks, in fact, any attackers can send OSPF packets d= irectly to an OSPF router and squeeze off its normal good packets. This is = a common problem in the IP routing, not specific to this draft. And this is also the reason that network designers are cautious not to let = their network be facing the subscribers directly. Regards, -wenhu ________________________________ From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Wednesday, March 30, 2011 5:29 AM To: Wenhu Lu; Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Wenhu, I am trying to say this: If you dont do verification in HW then you leave a hole open for DoS, which= means that you MUST do verification before flooding. However, this is easi= er said than done, and its extremely complex and convoluted to do this in H= W. And this is precisely why i had said "I'm saying that either ways you have = an issue." in my last mail that you responded to. Cheers, Manav ________________________________ From: Wenhu Lu [mailto:wenhu.lu@ericsson.com] Sent: Wednesday, March 30, 2011 5.51 PM To: Bhatia, Manav (Manav); Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Manav, If I read it correctly, your original message said there would be a hole if= we don't do verification in data plane. Now you are saying you never asser= ted it would, I'm confused. As Sri mentioned, the rate limiting should solve the problem easily. Thanks, -wenhu ________________________________ From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Wednesday, March 30, 2011 5:05 AM To: Wenhu Lu; Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Wenhu, I never asserted they would - If you claim to do auth verification in HW th= en you would presumably take care of this as well. I'm saying that either ways you have an issue. Cheers, Manav ________________________________ From: Wenhu Lu [mailto:wenhu.lu@ericsson.com] Sent: Wednesday, March 30, 2011 5.31 PM To: Bhatia, Manav (Manav); Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Manav, How would the data-plane auth verification prevent such DoS attacks? Any replayed packets will go through. Thanks, -wenhu ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bha= tia, Manav (Manav) Sent: Wednesday, March 30, 2011 12:55 AM To: Sriganesh Kini Cc: ospf@ietf.org Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Sri, This is regarding the point that i had raised yesterday - If the routers fl= ood the "LSAs" in the data plane without verifying them, then we're leaving= a hole open for DoS attacks, as any packet masquerading as a legitimate OS= PF packet will get flooded on all routers. This is different from data pack= ets flooding as these packets will be occupying the higest priority queues = in both the ingress, egress and the CPU. Second, what happens if the control packet is carrying an OSPF authenticati= on digest? Would you still flood it without verifying the contents or would= those be flooded regardless? I guess, you said that it would be the former= . If thats the case, then this is not easy to do it in the HW as you would = (i) need to parse the OSPF payload first to determine that its carrying a d= igest (ii) you would then need to verify it, which means you would be runni= ng HMAC-SHA in HW on the packet (given the Apad stuff that we have added in= RFC5709 i dont think you can easily do this in HW) (iii) once the digest i= s verified you would need to flood it out on all the valid OSPF interfaces. Cheers, Manav ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Sri= ganesh Kini Sent: Tuesday, March 29, 2011 9.20 PM To: ospf@ietf.org Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Just an FYI to the list This draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 = was presented at the OSPF WG mtg today. Thanks for the comments/questions at the mic. We will submit a new version = addressing the comments. Note that the other drafts related to Fast Notification (FN) are draft-lu-f= n-transport and draft-lu-fast-notification-framework. These were presented = in RTGWG. Thanks - Sri --_000_8249B703AE8442429AF89B86E8206AA26EF567C3D0EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Manav,
 
Verification in HW would mean more than auth che= ck. One=20 will have to move seq number check and lot of ospf logic into hardware, whi= ch as=20 you said is extremely complex. We tried to avoid this.
As for=20 the said DoS attacks, in fact, any attackers can send OSPF packets directly= to=20 an OSPF router and squeeze off its normal good packets. This is a comm= on=20 problem in the IP routing, not specific to this draft.
And=20 this is also the reason that network designers are cautious not to let thei= r=20 network be facing the subscribers directly.
 
Regards,
-wenhu

From: Bhatia, Manav (Manav)=20 [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Wednesday, March = 30,=20 2011 5:29 AM
To: Wenhu Lu; Sriganesh Kini
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi Wenhu,
 
I am trying to say this:
 
If you dont do verification in HW then you leave a= hole=20 open for DoS, which means that you MUST do verification before flooding.=20 However, this is easier said than done, and its extremely complex and convo= luted=20 to do this in HW.
 
And this is precisely why i had said "I'm = saying that=20 either ways you have an issue." in my last mail that you resp= onded=20 to.
 
Cheers, Manav
From: Wenhu Lu [mailto:wenhu.lu@erics= son.com]=20
Sent: Wednesday, March 30, 2011 5.51 PM
To: Bhatia, = Manav=20 (Manav); Sriganesh Kini
Cc: ospf@ietf.org
Subject: RE= :=20 [OSPF] FYI on draft-kini-ospf-fast-notification-01

Hi=20 Manav,
If I=20 read it correctly, your original message said there would be a hole if we= =20 don't do verification in data plane. Now you are saying you never=20 asserted it would, I'm confused.
As=20 Sri mentioned, the rate limiting should solve the problem=20 easily.
 
Thanks,
-wenhu

From: Bhatia, Manav (Manav)=20 [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Wednesday, Marc= h 30,=20 2011 5:05 AM
To: Wenhu Lu; Sriganesh Kini
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi Wenhu,
 
I never asserted they would - If you claim to do= auth=20 verification in HW then you would presumably take care of this as=20 well.
 
I'm saying that either ways you have an=20 issue.
 
Cheers, Manav

From: Wenhu Lu=20 [mailto:wenhu.lu@ericsson.com]
Sent: Wednesday, March 30, 20= 11=20 5.31 PM
To: Bhatia, Manav (Manav); Sriganesh Kini
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi=20 Manav,
How would the data-plane auth verification prevent such DoS=20 attacks?
Any replayed packets will go through.
 
Thanks,
-wenhu

From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Bhatia, Manav=20 (Manav)
Sent: Wednesday, March 30, 2011 12:55 AM
To:=20 Sriganesh Kini
Cc: ospf@ietf.org
Subject: Re: [OSPF= ] FYI=20 on draft-kini-ospf-fast-notification-01

Hi Sri,
 
This is regarding the point that i had raise= d=20 yesterday - If the routers flood the "LSAs" in the data plane without=20 verifying them, then we're leaving a hole open for DoS attacks, as any= =20 packet masquerading as a legitimate OSPF packet will get flooded on all= =20 routers. This is different from data packets flooding as these packets = will=20 be occupying the higest priority queues in both the ingress, egress and= the=20 CPU.
 
Second, what happens if the control packet i= s=20 carrying an OSPF authentication digest? Would you still flood it withou= t=20 verifying the contents or would those be flooded regardless? I guess, y= ou=20 said that it would be the former. If thats the case, then this is not e= asy=20 to do it in the HW as you would (i) need to parse the OSPF payload firs= t to=20 determine that its carrying a digest (ii) you would then need to verify= it,=20 which means you would be running HMAC-SHA in HW on the packet (given th= e=20 Apad stuff that we have added in RFC5709 i dont think you can easily do= this=20 in HW) (iii) once the digest is verified you would need to flood it out= on=20 all the valid OSPF interfaces.
 
Cheers,= =20 Manav
From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Sriganesh=20 Kini
Sent: Tuesday, March 29, 2011 9.20 PM
To:=20 ospf@ietf.org
Subject: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Jus= t an FYI to=20 the list
 
Thi= s draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification= -01 was=20 presented at the OSPF WG mtg today.
 
Tha= nks for the=20 comments/questions at the mic. We will submit a new version addressin= g the=20 comments.
 
Not= e that the=20 other drafts related to Fast Notification (FN) are draft-lu-fn-transp= ort=20 and draft-lu-fast-notification-framework. These were presented in=20 RTGWG.
 
Thanks

- Sri= =20

--_000_8249B703AE8442429AF89B86E8206AA26EF567C3D0EUSAACMS0703e_-- From manav.bhatia@alcatel-lucent.com Wed Mar 30 07:22:39 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B421E3A6B5D for ; Wed, 30 Mar 2011 07:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.72 X-Spam-Level: X-Spam-Status: No, score=-6.72 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu+SophLYqfg for ; Wed, 30 Mar 2011 07:22:37 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 291AA3A6A34 for ; Wed, 30 Mar 2011 07:22:37 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p2UEOA0I022544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2011 09:24:13 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2UEO9wt002543 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Mar 2011 19:54:10 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 30 Mar 2011 19:54:09 +0530 From: "Bhatia, Manav (Manav)" To: Wenhu Lu , Sriganesh Kini Date: Wed, 30 Mar 2011 19:54:20 +0530 Thread-Topic: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Thread-Index: AcvuKPPJkEhNbNnJQRC0V7XzEph3oQAhNhvgAAjMLrAAAFgioAAANE8wAACXR0AAAP3B4AADGifA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF66B1C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66A60@INBANSXCHMBSA1.in.alcatel-lucent.com> <8249B703AE8442429AF89B86E8206AA26EF567C38D@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66AF9@INBANSXCHMBSA1.in.alcatel-lucent.com> <8249B703AE8442429AF89B86E8206AA26EF567C39D@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66B06@INBANSXCHMBSA1.in.alcatel-lucent.com> <8249B703AE8442429AF89B86E8206AA26EF567C3D0@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <8249B703AE8442429AF89B86E8206AA26EF567C3D0@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350CFCF66B1CINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "ospf@ietf.org" Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 14:22:40 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFCF66B1CINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Right but there is a big difference - Today, if somebody inundates a router= with OSPF packets, its just this router that gets affected. With your prop= osal, since all these packets will get flooded, all the other routers would= get affected as well. In addition, it will also affect the data traffic as= described earlier. So, there is quite a bit of difference in the two cases= . Cheers, Manav ________________________________ From: Wenhu Lu [mailto:wenhu.lu@ericsson.com] Sent: Wednesday, March 30, 2011 6.41 PM To: Bhatia, Manav (Manav); Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Manav, Verification in HW would mean more than auth check. One will have to move s= eq number check and lot of ospf logic into hardware, which as you said is e= xtremely complex. We tried to avoid this. As for the said DoS attacks, in fact, any attackers can send OSPF packets d= irectly to an OSPF router and squeeze off its normal good packets. This is = a common problem in the IP routing, not specific to this draft. And this is also the reason that network designers are cautious not to let = their network be facing the subscribers directly. Regards, -wenhu ________________________________ From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Wednesday, March 30, 2011 5:29 AM To: Wenhu Lu; Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Wenhu, I am trying to say this: If you dont do verification in HW then you leave a hole open for DoS, which= means that you MUST do verification before flooding. However, this is easi= er said than done, and its extremely complex and convoluted to do this in H= W. And this is precisely why i had said "I'm saying that either ways you have = an issue." in my last mail that you responded to. Cheers, Manav ________________________________ From: Wenhu Lu [mailto:wenhu.lu@ericsson.com] Sent: Wednesday, March 30, 2011 5.51 PM To: Bhatia, Manav (Manav); Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Manav, If I read it correctly, your original message said there would be a hole if= we don't do verification in data plane. Now you are saying you never asser= ted it would, I'm confused. As Sri mentioned, the rate limiting should solve the problem easily. Thanks, -wenhu ________________________________ From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Wednesday, March 30, 2011 5:05 AM To: Wenhu Lu; Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Wenhu, I never asserted they would - If you claim to do auth verification in HW th= en you would presumably take care of this as well. I'm saying that either ways you have an issue. Cheers, Manav ________________________________ From: Wenhu Lu [mailto:wenhu.lu@ericsson.com] Sent: Wednesday, March 30, 2011 5.31 PM To: Bhatia, Manav (Manav); Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Manav, How would the data-plane auth verification prevent such DoS attacks? Any replayed packets will go through. Thanks, -wenhu ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bha= tia, Manav (Manav) Sent: Wednesday, March 30, 2011 12:55 AM To: Sriganesh Kini Cc: ospf@ietf.org Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Sri, This is regarding the point that i had raised yesterday - If the routers fl= ood the "LSAs" in the data plane without verifying them, then we're leaving= a hole open for DoS attacks, as any packet masquerading as a legitimate OS= PF packet will get flooded on all routers. This is different from data pack= ets flooding as these packets will be occupying the higest priority queues = in both the ingress, egress and the CPU. Second, what happens if the control packet is carrying an OSPF authenticati= on digest? Would you still flood it without verifying the contents or would= those be flooded regardless? I guess, you said that it would be the former= . If thats the case, then this is not easy to do it in the HW as you would = (i) need to parse the OSPF payload first to determine that its carrying a d= igest (ii) you would then need to verify it, which means you would be runni= ng HMAC-SHA in HW on the packet (given the Apad stuff that we have added in= RFC5709 i dont think you can easily do this in HW) (iii) once the digest i= s verified you would need to flood it out on all the valid OSPF interfaces. Cheers, Manav ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Sri= ganesh Kini Sent: Tuesday, March 29, 2011 9.20 PM To: ospf@ietf.org Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Just an FYI to the list This draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 = was presented at the OSPF WG mtg today. Thanks for the comments/questions at the mic. We will submit a new version = addressing the comments. Note that the other drafts related to Fast Notification (FN) are draft-lu-f= n-transport and draft-lu-fast-notification-framework. These were presented = in RTGWG. Thanks - Sri --_000_7C362EEF9C7896468B36C9B79200D8350CFCF66B1CINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Right but there is a big difference - Today, if so= mebody=20 inundates a router with OSPF packets, its just this router that gets affect= ed.=20 With your proposal, since all these packets will get flooded, all the other= =20 routers would get affected as well. In addition, it will also affect the da= ta=20 traffic as described earlier. So, there is quite a bit of difference in the= two=20 cases.
 
Cheers, Manav

From: Wenhu Lu [mailto:wenhu.lu@erics= son.com]=20
Sent: Wednesday, March 30, 2011 6.41 PM
To: Bhatia, = Manav=20 (Manav); Sriganesh Kini
Cc: ospf@ietf.org
Subject: RE= :=20 [OSPF] FYI on draft-kini-ospf-fast-notification-01

Hi=20 Manav,
 
Verification in HW would mean more than auth c= heck.=20 One will have to move seq number check and lot of ospf logic into hardwar= e,=20 which as you said is extremely complex. We tried to avoid=20 this.
As=20 for the said DoS attacks, in fact, any attackers can send OSPF packets=20 directly to an OSPF router and squeeze off its normal good packets. This= =20 is a common problem in the IP routing, not specific to this=20 draft.
And=20 this is also the reason that network designers are cautious not to let th= eir=20 network be facing the subscribers directly.
 
Regards,
-wenhu

From: Bhatia, Manav (Manav)=20 [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Wednesday, Marc= h 30,=20 2011 5:29 AM
To: Wenhu Lu; Sriganesh Kini
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi Wenhu,
 
I am trying to say this:
<= FONT=20 face=3DArial color=3D#0000ff size=3D2> 
If you dont do verification in HW then you leave= a hole=20 open for DoS, which means that you MUST do verification before flooding.= =20 However, this is easier said than done, and its extremely complex and=20 convoluted to do this in HW.
 
And this is precisely why i had said "I'= m saying that=20 either ways you have an issue." in my last mail that you=20 responded to.
 
Cheers, Manav
From: Wenhu Lu=20 [mailto:wenhu.lu@ericsson.com]
Sent: Wednesday, March 30, 20= 11=20 5.51 PM
To: Bhatia, Manav (Manav); Sriganesh Kini
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi=20 Manav,
If=20 I read it correctly, your original message said there would be a hole i= f we=20 don't do verification in data plane. Now you are saying you never= =20 asserted it would, I'm confused.
As=20 Sri mentioned, the rate limiting should solve the problem=20 easily.
 
Thanks,
-wenhu

From: Bhatia, Manav (Manav)=20 [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Wednesday, Ma= rch=20 30, 2011 5:05 AM
To: Wenhu Lu; Sriganesh Kini
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi Wenhu,
 
I never asserted they would - If you claim to = do auth=20 verification in HW then you would presumably take care of this as=20 well.
 
I'm saying that either ways you have an=20 issue.
 
Cheers, Manav

From: Wenhu Lu=20 [mailto:wenhu.lu@ericsson.com]
Sent: Wednesday, March 30, = 2011=20 5.31 PM
To: Bhatia, Manav (Manav); Sriganesh Kini
Cc:= =20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi Manav,
How would the data-plane auth verification prevent such DoS= =20 attacks?
Any replayed packets will go through.
 
Thanks,
-wenhu

From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Bhatia, Manav=20 (Manav)
Sent: Wednesday, March 30, 2011 12:55 AM
To:<= /B>=20 Sriganesh Kini
Cc: ospf@ietf.org
Subject: Re: [OS= PF]=20 FYI on draft-kini-ospf-fast-notification-01

Hi Sri,
 
This is regarding the point that i had rai= sed=20 yesterday - If the routers flood the "LSAs" in the data plane without= =20 verifying them, then we're leaving a hole open for DoS attacks, as an= y=20 packet masquerading as a legitimate OSPF packet will get flooded on a= ll=20 routers. This is different from data packets flooding as these packet= s=20 will be occupying the higest priority queues in both the ingress, egr= ess=20 and the CPU.
 
Second, what happens if the control packet= is=20 carrying an OSPF authentication digest? Would you still flood it with= out=20 verifying the contents or would those be flooded regardless? I guess,= you=20 said that it would be the former. If thats the case, then this is not= easy=20 to do it in the HW as you would (i) need to parse the OSPF payload fi= rst=20 to determine that its carrying a digest (ii) you would then need to v= erify=20 it, which means you would be running HMAC-SHA in HW on the packet (gi= ven=20 the Apad stuff that we have added in RFC5709 i dont think you can eas= ily=20 do this in HW) (iii) once the digest is verified you would need to fl= ood=20 it out on all the valid OSPF interfaces.
 
Cheer= s,=20 Manav
From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Sriganesh=20 Kini
Sent: Tuesday, March 29, 2011 9.20 PM
To:= =20 ospf@ietf.org
Subject: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

J= ust an FYI=20 to the list
 
T= his draft=20 http://tools.ietf.org/html/draft-kini-ospf-fast-notificati= on-01 was=20 presented at the OSPF WG mtg today.
 
T= hanks for=20 the comments/questions at the mic. We will submit a new version=20 addressing the comments.
 
N= ote that=20 the other drafts related to Fast Notification (FN) are=20 draft-lu-fn-transport and draft-lu-fast-notification-framework. The= se=20 were presented in RTGWG.
 
Thanks

- Sri=20

--_000_7C362EEF9C7896468B36C9B79200D8350CFCF66B1CINBANSXCHMBSA_-- From manav.bhatia@alcatel-lucent.com Wed Mar 30 08:24:49 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28D73A68B8; Wed, 30 Mar 2011 08:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.719 X-Spam-Level: X-Spam-Status: No, score=-6.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf06cUVizfYd; Wed, 30 Mar 2011 08:24:48 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id B48EF3A6847; Wed, 30 Mar 2011 08:24:48 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2UFQNTb015713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2011 10:26:25 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2UFQM2E004903 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Mar 2011 20:56:22 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 30 Mar 2011 20:56:22 +0530 From: "Bhatia, Manav (Manav)" To: "ospf@ietf.org" , "karp@ietf.org" Date: Wed, 30 Mar 2011 20:56:30 +0530 Thread-Topic: Securing the source IP in OSPF Thread-Index: Acvu7tgQXxp0oLMAR5uSduO0/re6CQ== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF66B2B@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [OSPF] Securing the source IP in OSPF X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:24:49 -0000 Hi, Because of paucity of time I did not discuss the IP header protection for O= SPF Security. I would request people to go through section 6 - "Mechanism to secure the I= P header" of http://tools.ietf.org/html/draft-bhatia-karp-ospf-ip-layer-pro= tection-03 and let us know if they have any concerns with that section. Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From glen.kent@gmail.com Wed Mar 30 12:47:58 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829893A6A7F; Wed, 30 Mar 2011 12:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCGPgQkLGB2V; Wed, 30 Mar 2011 12:47:57 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DCBDF3A68E0; Wed, 30 Mar 2011 12:47:55 -0700 (PDT) Received: by wwa36 with SMTP id 36so1372450wwa.13 for ; Wed, 30 Mar 2011 12:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sPrZT6nfkHukC1n5qIk3hRNWtiOfqhBCC6iAIgH2uoY=; b=S9O3wXEGKcbeq2Dzc+eNLBUEso0LugubIXsauP90e0FEZnk0v0XJiwIOfhVgUI1PQ6 5nvCMg5dMaBygqnxUBDD4OBMZz4VfU4iYdPvo3yysMEG8hoa3fulSXfZFdEecgEM9Vn5 cY0yUu1W4bRNFmOZHCKlQsES54U8FMDAqOwPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sBxLZGJvvuFI2WGslYAIW+8E1fjmUryVAuoOnNlG+FGJ+NW+5mXMOO9phQrEa5ltPR myN15xWDG5kdhWu8M2QpJ1Vics5ujCk9kA/3g2H1pFgV6XSPcs7G35hlrynIReh6cShe VPNQiYzMrMpWlSaI8P5AO8YIhRaoYfEW82b9k= MIME-Version: 1.0 Received: by 10.227.179.140 with SMTP id bq12mr1800675wbb.152.1301514573967; Wed, 30 Mar 2011 12:49:33 -0700 (PDT) Received: by 10.227.21.166 with HTTP; Wed, 30 Mar 2011 12:49:33 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFCF66B2B@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFCF66B2B@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 31 Mar 2011 01:19:33 +0530 Message-ID: From: Glen Kent To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] Securing the source IP in OSPF X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 19:47:58 -0000 Assuming that you will create a new Auth type i think this must be done unless the Apad has that fixed value because of some particular reason. I suspect that its just a random value that one usually finds in the security literature. It could have as well been 0xdeadbeef or 0xdeadbabe. Glen On Wed, Mar 30, 2011 at 8:56 PM, Bhatia, Manav (Manav) wrote: > > Hi, > > Because of paucity of time I did not discuss the IP header protection for OSPF Security. > > I would request people to go through section 6 - "Mechanism to secure the IP header" of http://tools.ietf.org/html/draft-bhatia-karp-ospf-ip-layer-protection-03 and let us know if they have any concerns with that section. > > Cheers, Manav > > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From manav.bhatia@alcatel-lucent.com Wed Mar 30 19:47:35 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BA33A6BF1; Wed, 30 Mar 2011 19:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.715 X-Spam-Level: X-Spam-Status: No, score=-6.715 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtgxtIaw0kOp; Wed, 30 Mar 2011 19:47:33 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id C65733A6BF0; Wed, 30 Mar 2011 19:47:33 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p2V2n9Ir007944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2011 21:49:11 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2V2n8kn008636 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Mar 2011 08:19:08 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 31 Mar 2011 08:19:08 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" , "ospf@ietf.org" Date: Thu, 31 Mar 2011 08:19:04 +0530 Thread-Topic: Regarding the replay attacks in routing protocols Thread-Index: AcvvTjK0vpHOKISuSFGYYUQpZJJEdA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF66B6A@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [OSPF] Regarding the replay attacks in routing protocols X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 02:47:35 -0000 Hi, I would urge the members of KARP WG to go through the two anti-replay mecha= nisms described in http://tools.ietf.org/html/draft-bhatia-karp-ospf-ip-lay= er-protection-03 One extends the current sequence number space from 32 bits to 64 bits, wher= e the most significant 32 bits indicate the number of times the router has = cold booted. This value can be fetched from the non-volatile memory, flash = or some remote server (which may also possibly store the image, startup con= figs, etc). This value would be generic and we envisage all the other routi= ng and signaling protocols using this in future. Thus BFD, LDP, etc can ext= end their crypto sequence space and use this value as the most significant = 32 bits. The second entails a session ID that's maintained for each session and a no= nce that guarantees that you are speaking to a live router. The session ID = needs to be carried around in the protocol packets so that everyone knows t= he right context. The former is patently easier to implement. It requires no change on the re= ceiving side. It requires very little change on the sending side and specif= ically the protocol machinery. For extremely low end devices (in the near f= uture when small sensor devices may run OSPF to discover each other) that d= o not have nvram or cannot store information on some remote device we could= fall back to the second solution, or decide not to provide an inter-sessio= n replay attack protection mechanism. Alternately, we could progress both the solutions and let the market decide= which solution gains widespread usage. I am guessing that it will be the f= ormer because of its simplistic design. I thus propose to split the current= draft into two where the base document describes the boot count and the ot= her that explains the Session ID and Nonces. We already have a generic draft draft-bhz-karp-inter-session-replay-00 that= will be presented in KARP tomorrow. Once this is accepted as a WG item oth= er protocols (OSPF, BFD, LDP, etc) can refer to this and extend their seque= nce space to prevent against inter-session replay attacks. We already have an OSPF document draft-bhatia-karp-ospf-ip-layer-protection= -03 that has been extensively discussed on the mailing lists and we can tri= m it significantly if we just provide reference to the above KARP document. Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From curtis@occnc.com Thu Mar 31 01:22:15 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C883A6B2B; Thu, 31 Mar 2011 01:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x04LC7-09B+a; Thu, 31 Mar 2011 01:22:14 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 6BC923A6826; Thu, 31 Mar 2011 01:22:14 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p2V8NrGN047454; Thu, 31 Mar 2011 04:23:53 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103310823.p2V8NrGN047454@harbor.orleans.occnc.com> To: "karp@ietf.org" , "ospf@ietf.org" From: Curtis Villamizar Date: Thu, 31 Mar 2011 04:23:53 -0400 Sender: curtis@occnc.com Subject: [OSPF] draft-bhatia-karp-ospf-ip-layer-protection-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:22:15 -0000 If a challenge response and session ID is going to be used, the nonce need not be carried after the session-id is negociated. The purpose of a nonce is to provide a challenge which the other end must encrypt and send back using a shared key or its private half of a public/private key pair. The nonce in both directions plus a session key must be exchanged and then after that the session key is used. To prevent replay, the session key and a monotonically increasing sequence number must be exchanged for subsequent packets. In pictures: session + challenge1 -> <- session + response1 + challenge2 session + response2 -> where: response1 = encrypt(session + challenge1) response2 = encrypt(session + challenge2) If you are going to keep that sort of method, then it needs to be used correctly. Only the session ID is needed after negociation. It would be better to exchange a session key rather than just a session ID. The reason to do this is so as not to use the same session key over a long period of time and to use the shared or public/private keys infrequently to provide very little data on which to try to reverse engineer the keys. I don't have strong feeling about whether this type of session ID should be used or whether the monotonicly increasing reboot count would be sufficient. I have some concerns about a CPU card going down or entire router catching fire and being replaced and not knowing what the reboot count was on the old CPU. The challenge/response has no requirement for a monotonically increasing reboot count variable. This may be a call for OSPF but KARP buy-in IMHO this conversation should be directed to either OSPF or KARP for now and not both but I cross posted since Manav cross posted a request to consider the security mechanisms in this draft. OTOH, this sort of session key negociation could be generic to other protocols (and quite frankly I borrowed the idea from the well documented kerberos tgt exchange and other challenge reponse use). Curtis From curtis@occnc.com Thu Mar 31 04:54:28 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B470C3A6B3C; Thu, 31 Mar 2011 04:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDzJLqO2DjKL; Thu, 31 Mar 2011 04:54:27 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 8E4703A6875; Thu, 31 Mar 2011 04:54:27 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p2VBsmrB083180; Thu, 31 Mar 2011 07:54:48 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103311154.p2VBsmrB083180@harbor.orleans.occnc.com> To: "Dacheng Zhang(Dacheng)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 31 Mar 2011 09:31:39 -0000." Date: Thu, 31 Mar 2011 07:54:48 -0400 Sender: curtis@occnc.com Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [OSPF] [karp] draft-bhatia-karp-ospf-ip-layer-protection-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:54:28 -0000 In message "Dacheng Zhang(Dacheng)" writes: > > >>It would be better to exchange a session key rather than just a > >>session ID. The reason to do this is so as not to use the same > >>session key over a long period of time and to use the shared or > >>public/private keys infrequently to provide very little data on which > >>to try to reverse engineer the keys. > > This draft assumes there is no automatic key management system > provided. If there is a auto KMP, challenge/response solution will not > be needed. Do you suggest that we should integrate a key negotiation > process in OSPF? This is about a session key. The session key is determined through an exchange that makes use of a shared or public/private key. OSPF has had a clear text password for decades and better authentication as time goes on that didn't put the key (password) in the clear. A shared key already exists so now new key management is being suggested. Curtis From wenhu.lu@ericsson.com Thu Mar 31 16:20:26 2011 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0763A69C8 for ; Thu, 31 Mar 2011 16:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH6hbGfpadlt for ; Thu, 31 Mar 2011 16:20:22 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 23F1C3A69C7 for ; Thu, 31 Mar 2011 16:20:22 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2VNLx2w004982 for ; Thu, 31 Mar 2011 18:22:01 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 31 Mar 2011 19:21:58 -0400 From: Wenhu Lu To: "ospf@ietf.org" Date: Thu, 31 Mar 2011 19:21:57 -0400 Thread-Topic: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Thread-Index: AcvuKPPJkEhNbNnJQRC0V7XzEph3oQAhNhvgAAjMLrAAAFgioAAANE8wAACXR0AASFZTgA== Message-ID: <8249B703AE8442429AF89B86E8206AA26EF56CB1EF@EUSAACMS0703.eamcs.ericsson.se> References: <5A5E55DF96F73844AF7DFB0F48721F0F5701F43A9B@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66A60@INBANSXCHMBSA1.in.alcatel-lucent.com> <8249B703AE8442429AF89B86E8206AA26EF567C38D@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66AF9@INBANSXCHMBSA1.in.alcatel-lucent.com> <8249B703AE8442429AF89B86E8206AA26EF567C39D@EUSAACMS0703.eamcs.ericsson.se> <7C362EEF9C7896468B36C9B79200D8350CFCF66B06@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFCF66B06@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8249B703AE8442429AF89B86E8206AA26EF56CB1EFEUSAACMS0703e_" MIME-Version: 1.0 Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 23:20:26 -0000 --_000_8249B703AE8442429AF89B86E8206AA26EF56CB1EFEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI the authors and Manav had a good hall way talk and it turned out that w= e need some clarifications: 1. the fast-notification is a special packet created and sent upon certain = events such as a link breakage. The normal ospf packets like hello, dd, lsa= will go as is and will not be "fast-flooded". 2. the special fn packets can be either a newly defined packet format, or j= ust an LSA but with a pre-defined multicast group address MC-FN (c.f. draft= ) which is different than regular OSPF group addresses. 3. Only fn packets will be put on and flooded through the said multicast tr= ees. Other type of packets will not. 4. The dampening mechanism will be placed in the forwarding plane to preven= t the potential DoS attacks. We plan to update our draft to a newer version which will include more clar= ifications. We thank Manav and others for many constructive comments and questions. In the meanwhile, we welcome and solicit more comments and suggests and we = will incorpate them into the next revision. Thank you, -wenhu ________________________________ From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Wednesday, March 30, 2011 5:29 AM To: Wenhu Lu; Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Wenhu, I am trying to say this: If you dont do verification in HW then you leave a hole open for DoS, which= means that you MUST do verification before flooding. However, this is easi= er said than done, and its extremely complex and convoluted to do this in H= W. And this is precisely why i had said "I'm saying that either ways you have = an issue." in my last mail that you responded to. Cheers, Manav ________________________________ From: Wenhu Lu [mailto:wenhu.lu@ericsson.com] Sent: Wednesday, March 30, 2011 5.51 PM To: Bhatia, Manav (Manav); Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Manav, If I read it correctly, your original message said there would be a hole if= we don't do verification in data plane. Now you are saying you never asser= ted it would, I'm confused. As Sri mentioned, the rate limiting should solve the problem easily. Thanks, -wenhu ________________________________ From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Wednesday, March 30, 2011 5:05 AM To: Wenhu Lu; Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Wenhu, I never asserted they would - If you claim to do auth verification in HW th= en you would presumably take care of this as well. I'm saying that either ways you have an issue. Cheers, Manav ________________________________ From: Wenhu Lu [mailto:wenhu.lu@ericsson.com] Sent: Wednesday, March 30, 2011 5.31 PM To: Bhatia, Manav (Manav); Sriganesh Kini Cc: ospf@ietf.org Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Manav, How would the data-plane auth verification prevent such DoS attacks? Any replayed packets will go through. Thanks, -wenhu ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bha= tia, Manav (Manav) Sent: Wednesday, March 30, 2011 12:55 AM To: Sriganesh Kini Cc: ospf@ietf.org Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Hi Sri, This is regarding the point that i had raised yesterday - If the routers fl= ood the "LSAs" in the data plane without verifying them, then we're leaving= a hole open for DoS attacks, as any packet masquerading as a legitimate OS= PF packet will get flooded on all routers. This is different from data pack= ets flooding as these packets will be occupying the higest priority queues = in both the ingress, egress and the CPU. Second, what happens if the control packet is carrying an OSPF authenticati= on digest? Would you still flood it without verifying the contents or would= those be flooded regardless? I guess, you said that it would be the former= . If thats the case, then this is not easy to do it in the HW as you would = (i) need to parse the OSPF payload first to determine that its carrying a d= igest (ii) you would then need to verify it, which means you would be runni= ng HMAC-SHA in HW on the packet (given the Apad stuff that we have added in= RFC5709 i dont think you can easily do this in HW) (iii) once the digest i= s verified you would need to flood it out on all the valid OSPF interfaces. Cheers, Manav ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Sri= ganesh Kini Sent: Tuesday, March 29, 2011 9.20 PM To: ospf@ietf.org Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01 Just an FYI to the list This draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 = was presented at the OSPF WG mtg today. Thanks for the comments/questions at the mic. We will submit a new version = addressing the comments. Note that the other drafts related to Fast Notification (FN) are draft-lu-f= n-transport and draft-lu-fast-notification-framework. These were presented = in RTGWG. Thanks - Sri --_000_8249B703AE8442429AF89B86E8206AA26EF56CB1EFEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI=20 the authors and Manav had a good hall way talk and it turned out that we ne= ed=20 some clarifications:
1. the=20 fast-notification is a special packet created and sent upon certain events = such=20 as a link breakage. The normal ospf packets like hello, dd, lsa will g= o as=20 is and will not be "fast-flooded".
2. the=20 special fn packets can be either a newly defined packet format, or just an = LSA=20 but with a pre-defined multicast group address MC-FN (c.f. draft) which is= =20 different than regular OSPF group addresses.
3.=20 Only fn packets will be put on and flooded through the said multicast= =20 trees. Other type of packets will not.
4. The=20 dampening mechanism will be placed in the forwarding plane to pre= vent=20 the potential DoS attacks.
 
We=20 plan to update our draft to a newer version which will include more=20 clarifications.
We=20 thank Manav and others for many constructive comments and=20 questions.
In the=20 meanwhile, we welcome and solicit more comments and suggests and we wi= ll=20 incorpate them into the next revision.
 
Thank=20 you,
-wenhu

From: Bhatia, Manav (Manav)=20 [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Wednesday, March = 30,=20 2011 5:29 AM
To: Wenhu Lu; Sriganesh Kini
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi Wenhu,
 
I am trying to say this:
 
If you dont do verification in HW then you leave a= hole=20 open for DoS, which means that you MUST do verification before flooding.=20 However, this is easier said than done, and its extremely complex and convo= luted=20 to do this in HW.
 
And this is precisely why i had said "I'm = saying that=20 either ways you have an issue." in my last mail that you resp= onded=20 to.
 
Cheers, Manav
From: Wenhu Lu [mailto:wenhu.lu@erics= son.com]=20
Sent: Wednesday, March 30, 2011 5.51 PM
To: Bhatia, = Manav=20 (Manav); Sriganesh Kini
Cc: ospf@ietf.org
Subject: RE= :=20 [OSPF] FYI on draft-kini-ospf-fast-notification-01

Hi=20 Manav,
If I=20 read it correctly, your original message said there would be a hole if we= =20 don't do verification in data plane. Now you are saying you never=20 asserted it would, I'm confused.
As=20 Sri mentioned, the rate limiting should solve the problem=20 easily.
 
Thanks,
-wenhu

From: Bhatia, Manav (Manav)=20 [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Wednesday, Marc= h 30,=20 2011 5:05 AM
To: Wenhu Lu; Sriganesh Kini
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi Wenhu,
 
I never asserted they would - If you claim to do= auth=20 verification in HW then you would presumably take care of this as=20 well.
 
I'm saying that either ways you have an=20 issue.
 
Cheers, Manav

From: Wenhu Lu=20 [mailto:wenhu.lu@ericsson.com]
Sent: Wednesday, March 30, 20= 11=20 5.31 PM
To: Bhatia, Manav (Manav); Sriganesh Kini
Cc:=20 ospf@ietf.org
Subject: RE: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Hi=20 Manav,
How would the data-plane auth verification prevent such DoS=20 attacks?
Any replayed packets will go through.
 
Thanks,
-wenhu

From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Bhatia, Manav=20 (Manav)
Sent: Wednesday, March 30, 2011 12:55 AM
To:=20 Sriganesh Kini
Cc: ospf@ietf.org
Subject: Re: [OSPF= ] FYI=20 on draft-kini-ospf-fast-notification-01

Hi Sri,
 
This is regarding the point that i had raise= d=20 yesterday - If the routers flood the "LSAs" in the data plane without=20 verifying them, then we're leaving a hole open for DoS attacks, as any= =20 packet masquerading as a legitimate OSPF packet will get flooded on all= =20 routers. This is different from data packets flooding as these packets = will=20 be occupying the higest priority queues in both the ingress, egress and= the=20 CPU.
 
Second, what happens if the control packet i= s=20 carrying an OSPF authentication digest? Would you still flood it withou= t=20 verifying the contents or would those be flooded regardless? I guess, y= ou=20 said that it would be the former. If thats the case, then this is not e= asy=20 to do it in the HW as you would (i) need to parse the OSPF payload firs= t to=20 determine that its carrying a digest (ii) you would then need to verify= it,=20 which means you would be running HMAC-SHA in HW on the packet (given th= e=20 Apad stuff that we have added in RFC5709 i dont think you can easily do= this=20 in HW) (iii) once the digest is verified you would need to flood it out= on=20 all the valid OSPF interfaces.
 
Cheers,= =20 Manav
From: ospf-bounces@ietf.org=20 [mailto:ospf-bounces@ietf.org] On Behalf Of Sriganesh=20 Kini
Sent: Tuesday, March 29, 2011 9.20 PM
To:=20 ospf@ietf.org
Subject: [OSPF] FYI on=20 draft-kini-ospf-fast-notification-01

Jus= t an FYI to=20 the list
 
Thi= s draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification= -01 was=20 presented at the OSPF WG mtg today.
 
Tha= nks for the=20 comments/questions at the mic. We will submit a new version addressin= g the=20 comments.
 
Not= e that the=20 other drafts related to Fast Notification (FN) are draft-lu-fn-transp= ort=20 and draft-lu-fast-notification-framework. These were presented in=20 RTGWG.
 
Thanks

- Sri= =20

--_000_8249B703AE8442429AF89B86E8206AA26EF56CB1EFEUSAACMS0703e_--