From internet-drafts@ietf.org Fri Mar 9 08:02:02 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423E621F871A; Fri, 9 Mar 2012 08:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaVgHmvlBbmR; Fri, 9 Mar 2012 08:02:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C482621F8711; Fri, 9 Mar 2012 08:02:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309160201.22753.1572.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 08:02:01 -0800 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-threats-reqs-04.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:02:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing= Protocols Working Group of the IETF. Title : Keying and Authentication for Routing Protocols (KARP) O= verview, Threats, and Requirements Author(s) : Gregory Lebovitz Manav Bhatia Filename : draft-ietf-karp-threats-reqs-04.txt Pages : 32 Date : 2012-03-09 Different routing protocols exist and each employs its own mechanism for securing the protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed and a set of requirements for KARP design teams to follow. RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" is a companion to this document; KARP design teams will use them together to review and overhaul routing protocols. These two documents reflect the input of both the IETF's Security Area and Routing Area in order to form a mutually agreeable work plan. This document has three main parts. The first part provides an overview of the KARP effort. The second part lists the threats from RFC 4593, Generic Threats To Routing Protocols, that are in scope for attacks against routing protocols' transport systems, including any mechanisms built into the routing protocols themselves, which accomplish packet authentication. The third part enumerates the requirements that routing protocol specifications must meet when addressing those threats for RFC 6518's "Work Phase 1", the update to a routing protocol's existing transport security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-04.txt From internet-drafts@ietf.org Mon Mar 12 07:57:27 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA0021F8868; Mon, 12 Mar 2012 07:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN6XzfuM4MXF; Mon, 12 Mar 2012 07:57:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD71221F8864; Mon, 12 Mar 2012 07:57:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312145726.23272.96260.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 07:57:26 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-ospf-analysis-03.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:57:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing= Protocols Working Group of the IETF. Title : Analysis of OSPF Security According to KARP Design Guide Author(s) : Sam Hartman Dacheng Zhang Filename : draft-ietf-karp-ospf-analysis-03.txt Pages : 12 Date : 2012-03-12 This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in section 4.2 of draft-ietf-karp-design-guide. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-ospf-analysis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-ospf-analysis-03.txt From hartmans@mit.edu Mon Mar 12 16:48:19 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE2521E8261 for ; Mon, 12 Mar 2012 16:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=-1.246, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AvjzqAscKkj for ; Mon, 12 Mar 2012 16:48:19 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 27E4A21E825F for ; Mon, 12 Mar 2012 16:48:19 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7A22E2024B for ; Mon, 12 Mar 2012 19:47:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9AB4A4767; Mon, 12 Mar 2012 19:48:09 -0400 (EDT) From: Sam Hartman To: karp@ietf.org Cc: References: <20120312145726.23272.96260.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 19:48:09 -0400 In-Reply-To: <20120312145726.23272.96260.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Mon, 12 Mar 2012 07:57:26 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [karp] I-D Action: draft-ietf-karp-ospf-analysis-03.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:48:19 -0000 we've updated the OSPF analysis to bring it into consistency with the published design guide. The design guide now contains text about DOS attacks on the cryptographic authentication mechanism. We've discussed those issues in the OSPF analysis draft. We believe it's again ready for last call ass soon as the prerequisits are done. From mjethanandani@gmail.com Mon Mar 12 23:30:54 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C65A21F87BE for ; Mon, 12 Mar 2012 23:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qiVA054foyI for ; Mon, 12 Mar 2012 23:30:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEA521F87BF for ; Mon, 12 Mar 2012 23:30:53 -0700 (PDT) Received: by iazz13 with SMTP id z13so400593iaz.31 for ; Mon, 12 Mar 2012 23:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; bh=YD5akUk/AiXTVWPL/H0eRkkgOyoGqOdOMEoZpPxO6lE=; b=sW43/6DdgpfejtA+9o4OgDC8KXvyiqOCM7wid6A+q9puywPo2hKbypK9pxIZoV9/xh D3yU+xEjmHcdOjFnveelUaN3ElDQJfpmk9DIlqj4xhg29pTqdV0hlfBzTC/O6/sZu2hx g1jJwcVTkJDB7mmWclYv/koIemAZSw9Mz7KvginxREZSxgWTFfWWJhM2avYanX2/VB5d jNuR7Uh+9ViMfucotkFUvXFEWzFeyHU6oL6VhJZpnTimtPngj7pcSY85ys/PVhrBGy1b vStO7jtxOs6iLjFrO7F6yuqTiSrix11MnidXHLvPabiTjU+NIXi+jNhFKI6yeiBg0dqW xe/A== Received: by 10.43.49.199 with SMTP id vb7mr19384200icb.9.1331620253146; Mon, 12 Mar 2012 23:30:53 -0700 (PDT) Received: from [192.168.1.123] (c-24-6-173-225.hsd1.ca.comcast.net. [24.6.173.225]) by mx.google.com with ESMTPS id zv10sm10930288igb.13.2012.03.12.23.30.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Mar 2012 23:30:52 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=Apple-Mail-82--1021752033 Date: Mon, 12 Mar 2012 23:30:49 -0700 References: <82398C6B-76A1-4392-96C5-7888FD6BA537@cisco.com> To: "karp@ietf.org karp@ietf.org" Message-Id: <75843A3C-0D6E-4420-9D63-E6DB6D59BC9B@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [karp] Fwd: New Version Notification for draft-mahesh-karp-rkmp-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 06:30:54 -0000 --Apple-Mail-82--1021752033 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please read and provide comments. >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-mahesh-karp-rkmp-01.txt >> Date: March 8, 2012 8:09:49 AM PST >> To: mjethanandani@gmail.com >> Cc: keyupate@cisco.com, hartmans@painless-security.com, = zhangdacheng@huawei.com, bew@cisco.com >>=20 >> A new version of I-D, draft-mahesh-karp-rkmp-01.txt has been = successfully submitted by Mahesh Jethanandani and posted to the IETF = repository. >>=20 >> Filename: draft-mahesh-karp-rkmp >> Revision: 01 >> Title: Key Management for Pairwise Routing Protocol >> Creation date: 2012-03-08 >> WG ID: Individual Submission >> Number of pages: 16 >>=20 >> Abstract: >> When running routing protocols such as BGP or RSVP-TE, two routers >> need to exchange routing messages in a unicast (one-to-one) fashion. >> In order to authenticate these messages using symmetric = cryptography, >> a secret key needs to be established. This document defines a = Router >> Key Management Protocol for establishing and managing such keys for >> routing protocols. >>=20 >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 >=20 >=20 >=20 >=20 --Apple-Mail-82--1021752033 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Begin forwarded message:

From: internet-drafts@ietf.org
<= /blockquote>
Subject: New Version Notification = for draft-mahesh-karp-rkmp-01.txt
Date: March 8, 2012 8:09:49 AM = PST
To: mjethanandani@gmail.com
Cc: keyupate@cisco.com, hartmans@painless-security.= com, zhangdacheng@huawei.com, bew@cisco.com

A new version = of I-D, draft-mahesh-karp-rkmp-01.txt has been successfully submitted by = Mahesh Jethanandani and posted to the IETF = repository.

Filename: = draft-mahesh-karp-rkmp
Revision: 01
Title: Key Management for Pairwise = Routing Protocol
Creation = date: = 2012-03-08
WG ID: = Individual Submission
Number = of pages: 16

Abstract:
=  When running routing protocols such as BGP or RSVP-TE, two = routers
 need to = exchange routing messages in a unicast (one-to-one) = fashion.
 In order to = authenticate these messages using symmetric = cryptography,
 a secret = key needs to be established.  This document defines a = Router
 Key Management = Protocol for establishing and managing such keys = for
 routing = protocols.





The IETF = Secretariat





<= br>= --Apple-Mail-82--1021752033-- From bew@cisco.com Tue Mar 13 11:36:39 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB67B21F8796 for ; Tue, 13 Mar 2012 11:36:39 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6c1MeXEr5K4 for ; Tue, 13 Mar 2012 11:36:39 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4F39F21F871C for ; Tue, 13 Mar 2012 11:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=181; q=dns/txt; s=iport; t=1331663799; x=1332873399; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=xZ+h1kbcEFFqgEmVbUIwVw60mteKOV3khHKzfskjP9k=; b=jt/MM5tgedpVhSknijDo7du14kG/Ip3RbGJWwvOT0v1+ZSK4NeAzYf2f r7w/TKWAnhysBZOhok2tXdeX/lG2lXBKrPrvQqaAMh2FxrXs/FFYKKXs3 FEunTwJiLAt9hGFPQyGMs6OyxVEf/ueRCJamW7H35r3p7TEEVZ928kg4M Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAPuSX0+rRDoJ/2dsb2JhbABDtWuBB4IiAQodghAih2ebdoEnAZ8FjUOCP2MEiFWMe5AjgwWBPA X-IronPort-AV: E=Sophos;i="4.73,578,1325462400"; d="scan'208";a="32926678" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 13 Mar 2012 18:36:39 +0000 Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2DIac9T026817 for ; Tue, 13 Mar 2012 18:36:39 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Mar 2012 11:36:38 -0700 Message-Id: <9EC537FC-EA83-4662-940A-7209BF3002EE@cisco.com> To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [karp] Call for IETF 83 agenda items (KARP) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 18:36:39 -0000 The KARP WG will be meeting Wednesday afternoon in Paris. If you have a = topic for the meeting please email the chairs = (karp-chairs@tools.ietf.org). Thanks, Brian & Joel= From hartmans@mit.edu Thu Mar 15 08:37:27 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CC321F8722 for ; Thu, 15 Mar 2012 08:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.314 X-Spam-Level: X-Spam-Status: No, score=-103.314 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lwvzE1TW9i4 for ; Thu, 15 Mar 2012 08:37:27 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 45CAD21F871E for ; Thu, 15 Mar 2012 08:37:27 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 56379207B7 for ; Thu, 15 Mar 2012 11:36:58 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E54A74767; Thu, 15 Mar 2012 11:37:13 -0400 (EDT) From: Sam Hartman To: karp@ietf.org Date: Thu, 15 Mar 2012 11:37:13 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [karp] threats-reqs: New requirements document for KMP X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:37:27 -0000 Hi. I noticed language (not sure if it is new) in 04 of threats-reqs that claims we'll be developing another requirements document related to KMP requirements. My personal opinion is that would be an unnecessary delay. I think there are aspects of the KMP discussion where we do better need to understand the requirements. For example, I don't think we have a good view about how KMP interacts with RP surrounding issues like TCP-AO's state, the key tables draft, etc. It's quite clear that Joe Touch and I have different ideas on some of this as an example. I think we should have those discussions. I think some consensus calls will need to be made even. However, I do not believe that having a full requirements document will be necessary to converge on a solution. I'd rather focus on technology than process. So as an individual I'm not in favor of a KMP requirements document nor am I in favor of blocking on its completion before moving forward on KMP work. From bew@cisco.com Thu Mar 15 14:17:29 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFAC21E8025 for ; Thu, 15 Mar 2012 14:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKDuOIch2n15 for ; Thu, 15 Mar 2012 14:17:28 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB1221E8011 for ; Thu, 15 Mar 2012 14:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1846; q=dns/txt; s=iport; t=1331846248; x=1333055848; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=xXJ2TVwa2pisV8qJQCQ0/t66hMo01YlZ8ocPfc8iNNU=; b=Q0TFmwNBARN/63mGq6IdgTMerzTuaue35URalUCYaYsWOEfS9F5iRQeE smJro9jEbqjNtpizrGd0FClsdXtpPiOpTUsUgBfi9ZGAfYdW2Kgu2dAPb OQEgLxtkeVuixeSlLmGdlXy5JXtzezmkZJwZvdoVYyJuTkO2HbLJyyaSn 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAZcYk+rRDoJ/2dsb2JhbABDDrYcgQeCCQEBAQMBAQEBDwEnNAsQC0YnMAYTGweHYwQBC5pwnn8EkCRjBIhXjQqOP4Fogi9X X-IronPort-AV: E=Sophos;i="4.73,592,1325462400"; d="scan'208";a="33199869" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 15 Mar 2012 21:17:11 +0000 Received: from dhcp-128-107-151-42.cisco.com (dhcp-128-107-151-42.cisco.com [128.107.151.42]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2FLHBIi030419; Thu, 15 Mar 2012 21:17:11 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: Date: Thu, 15 Mar 2012 14:17:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6EFEEA85-1E82-4592-A258-E350F5F8D45D@cisco.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1257) Cc: karp@ietf.org Subject: Re: [karp] threats-reqs: New requirements document for KMP X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 21:17:29 -0000 Hi Sam, Thanks for your review. This is new text responding to a reviewer = comment pointing out that this document only covers "PHASE 1" of the = KARP Design Guide (RFC 6518). I believe the main contribution of the new = text is to declare that "PHASE 2" is not being addressed in this I-D. = The text you are objecting to is parenthetical text promising another = requirements document. I propose removing this text and discussing the = need for another requirements document independently. Any objections from the authors or the WG? Brian (Document shepherd hat on) On Mar 15, 2012, at 8:37 AM, Sam Hartman wrote: >=20 > Hi. I noticed language (not sure if it is new) in 04 of threats-reqs > that claims we'll be developing another requirements document related = to > KMP requirements. >=20 > My personal opinion is that would be an unnecessary delay. =20 >=20 > I think there are aspects of the KMP discussion where we do better = need > to understand the requirements. For example, I don't think we have a > good view about how KMP interacts with RP surrounding issues like > TCP-AO's state, the key tables draft, etc. It's quite clear that Joe > Touch and I have different ideas on some of this as an example. I = think > we should have those discussions. I think some consensus calls will = need > to be made even. >=20 > However, I do not believe that having a full requirements document = will > be necessary to converge on a solution. I'd rather focus on technology > than process. >=20 > So as an individual I'm not in favor of a KMP requirements document = nor > am I in favor of blocking on its completion before moving forward on = KMP > work. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From hartmans@mit.edu Thu Mar 15 14:26:55 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA85121E8025 for ; Thu, 15 Mar 2012 14:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.275 X-Spam-Level: X-Spam-Status: No, score=-103.275 tagged_above=-999 required=5 tests=[AWL=-1.237, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVt1D+6ojS0s for ; Thu, 15 Mar 2012 14:26:55 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0B72F21E8010 for ; Thu, 15 Mar 2012 14:26:54 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A1FCE20289; Thu, 15 Mar 2012 17:26:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3EC784767; Thu, 15 Mar 2012 17:26:35 -0400 (EDT) From: Sam Hartman To: Brian Weis References: <6EFEEA85-1E82-4592-A258-E350F5F8D45D@cisco.com> Date: Thu, 15 Mar 2012 17:26:34 -0400 In-Reply-To: <6EFEEA85-1E82-4592-A258-E350F5F8D45D@cisco.com> (Brian Weis's message of "Thu, 15 Mar 2012 14:17:11 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] threats-reqs: New requirements document for KMP X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 21:26:56 -0000 >>>>> "Brian" == Brian Weis writes: Brian> Hi Sam, Thanks for your review. This is new text responding Brian> to a reviewer comment pointing out that this document only Brian> covers "PHASE 1" of the KARP Design Guide (RFC 6518). I Brian> believe the main contribution of the new text is to declare Brian> that "PHASE 2" is not being addressed in this I-D. The text Brian> you are objecting to is parenthetical text promising another Brian> requirements document. I propose removing this text and Brian> discussing the need for another requirements document Brian> independently. I support that proposal. From uma.chunduri@ericsson.com Thu Mar 15 14:31:54 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3419A21E8025 for ; Thu, 15 Mar 2012 14:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2m5SGCXkl3Q for ; Thu, 15 Mar 2012 14:31:53 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 86A5F21E8010 for ; Thu, 15 Mar 2012 14:31:53 -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 q2FLVKvl014799; Thu, 15 Mar 2012 16:31:52 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.140]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 15 Mar 2012 17:31:42 -0400 From: Uma Chunduri To: Brian Weis , Sam Hartman Date: Thu, 15 Mar 2012 17:31:41 -0400 Thread-Topic: [karp] threats-reqs: New requirements document for KMP Thread-Index: Ac0C8RdQ8FXB49MqSFOhrumNfNnafQAANzsw Message-ID: References: <6EFEEA85-1E82-4592-A258-E350F5F8D45D@cisco.com> In-Reply-To: <6EFEEA85-1E82-4592-A258-E350F5F8D45D@cisco.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: "karp@ietf.org" Subject: Re: [karp] threats-reqs: New requirements document for KMP X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 21:31:54 -0000 I don't see any objection here. On this note, I presume each protocol Gap analysis document should capture = both PHASE1 and PHASE2 (KMP) requirements.=20 We did this for IS-IS (http://datatracker.ietf.org/doc/draft-chunduri-karp-= is-is-gap-analysis/) --=20 Uma C.=20 -----Original Message----- From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Bri= an Weis Sent: Thursday, March 15, 2012 2:17 PM To: Sam Hartman Cc: karp@ietf.org Subject: Re: [karp] threats-reqs: New requirements document for KMP Hi Sam, Thanks for your review. This is new text responding to a reviewer comment p= ointing out that this document only covers "PHASE 1" of the KARP Design Gui= de (RFC 6518). I believe the main contribution of the new text is to declar= e that "PHASE 2" is not being addressed in this I-D. The text you are objec= ting to is parenthetical text promising another requirements document. I pr= opose removing this text and discussing the need for another requirements d= ocument independently. Any objections from the authors or the WG? Brian (Document shepherd hat on) On Mar 15, 2012, at 8:37 AM, Sam Hartman wrote: >=20 > Hi. I noticed language (not sure if it is new) in 04 of threats-reqs=20 > that claims we'll be developing another requirements document related=20 > to KMP requirements. >=20 > My personal opinion is that would be an unnecessary delay. =20 >=20 > I think there are aspects of the KMP discussion where we do better=20 > need to understand the requirements. For example, I don't think we=20 > have a good view about how KMP interacts with RP surrounding issues=20 > like TCP-AO's state, the key tables draft, etc. It's quite clear that=20 > Joe Touch and I have different ideas on some of this as an example. I=20 > think we should have those discussions. I think some consensus calls=20 > will need to be made even. >=20 > However, I do not believe that having a full requirements document=20 > will be necessary to converge on a solution. I'd rather focus on=20 > technology than process. >=20 > So as an individual I'm not in favor of a KMP requirements document=20 > nor am I in favor of blocking on its completion before moving forward=20 > on KMP work. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp From uma.chunduri@ericsson.com Thu Mar 15 15:01:30 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3733A21E8026 for ; Thu, 15 Mar 2012 15:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxhLlpSdYALw for ; Thu, 15 Mar 2012 15:01:29 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id AB34021E8010 for ; Thu, 15 Mar 2012 15:01:29 -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 q2FM1PU4019623; Thu, 15 Mar 2012 17:01:29 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.140]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 15 Mar 2012 18:01:26 -0400 From: Uma Chunduri To: Sam Hartman , "karp@ietf.org" Date: Thu, 15 Mar 2012 18:01:25 -0400 Thread-Topic: [karp] threats-reqs: New requirements document for KMP Thread-Index: Ac0CwYs80P4r5nPhT0OMEmxQa+jOFwANMf4w Message-ID: References: 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 Subject: Re: [karp] threats-reqs: New requirements document for KMP X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 22:01:30 -0000 Hi Sam, >>>I think there are aspects of the KMP discussion where we do better n= eed to understand the requirements.=20 >>>For example, I don't think we have a good view about how KMP interac= ts with RP surrounding issues=20 >>>like TCP-AO's state, the key tables draft, etc. It's quite clear tha= t Joe Touch and I have different=20 >>>ideas on some of this as an example. I think we should have those d= iscussions. I think some consensus=20 >>>calls will need to be made even. For your particular comment above, I see you are talking about TCP-based RP= s interaction.=20 We updated the AO-KMP document with Gatekeeper module presented in Taipei. = Could you spell specific differences you have on this? --=20 Uma C.=20 From hartmans@mit.edu Fri Mar 16 06:58:02 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B88C21F8619 for ; Fri, 16 Mar 2012 06:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.255 X-Spam-Level: X-Spam-Status: No, score=-103.255 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlPGqD4sH5Hh for ; Fri, 16 Mar 2012 06:58:01 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6059621F85ED for ; Fri, 16 Mar 2012 06:58:01 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2730C20289; Fri, 16 Mar 2012 09:57:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 31C124767; Fri, 16 Mar 2012 09:57:41 -0400 (EDT) From: Sam Hartman To: Uma Chunduri References: <6EFEEA85-1E82-4592-A258-E350F5F8D45D@cisco.com> Date: Fri, 16 Mar 2012 09:57:40 -0400 In-Reply-To: (Uma Chunduri's message of "Thu, 15 Mar 2012 17:31:41 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] threats-reqs: New requirements document for KMP X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 13:58:02 -0000 >>>>> "Uma" == Uma Chunduri writes: Uma> I don't see any objection here. On this note, I presume each Uma> protocol Gap analysis document should capture both PHASE1 and Uma> PHASE2 (KMP) requirements. We did this for IS-IS Uma> (http://datatracker.ietf.org/doc/draft-chunduri-karp-is-is-gap-analysis/) That's not clear to me. For IS-IS it seems worth starting to think about the phase 2 issues as soon as possible because I think that IS-IS has complex phase 2 requirements compared to other RPs. However I'd interpreted the gap analysis as a phase 1 effort. For most protocols I'd hope there are few if any phase 2 issues. If we're doing the right thing with the phase 1 work and the key tables, then protocols should look much the same to the KMP. Getting to that state is kind of a requirement for phase 1 outlined in section 4 of threats-reqs. From manav.bhatia@alcatel-lucent.com Sat Mar 17 00:21:13 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079BA21F8646 for ; Sat, 17 Mar 2012 00:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.762 X-Spam-Level: X-Spam-Status: No, score=-6.762 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly4asJb4kaOy for ; Sat, 17 Mar 2012 00:21:12 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0428A21F8636 for ; Sat, 17 Mar 2012 00:21:11 -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 q2H7L3kW004269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Mar 2012 02:21:10 -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 q2H7Kxch015697 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 17 Mar 2012 12:51:00 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Sat, 17 Mar 2012 12:50:59 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Sat, 17 Mar 2012 12:51:01 +0530 Thread-Topic: requirement 17 from karp-threat-reqs-03 Thread-Index: Ac0EDoGNOROIHCrTRiKfL8rdXs8PwQ== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02DB3D29@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: [karp] requirement 17 from karp-threat-reqs-03 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 07:21:13 -0000 Hi, Gregory, Brian and I had some discussion on what we wanted to do with the r= equirement 17 that existed in http://tools.ietf.org/html/draft-ietf-karp-th= reats-reqs-03 The requirement 17 was as follows: "The authentication mechanism does not provide message confidentiality, but= SHOULD NOT preclude the possibility of confidentiality support being added= in the future." The above text has been removed in the latest version and we would like to = solicit comments from the WG members on this issue. At the first glance the requirement seems to be absurd because an "authenti= cation mechanism" cannot by definition provide confidentiality. This can be= fixed by tweaking the text to say that the new security mechanism should p= rovide message integrity in addition to being able to support confidentiali= ty if required.=20 However, the bigger question is, that do we even want to keep this requirem= ent? Do we envisage a scenario in future where we might want to encrypt the= routing packets? If not, then we can safely remove this requirement. The r= eason this text was added was because certain people felt that we ought to = address confidentiality (and not just message integrity) of the routing pac= kets. The result of that discussion was this text where we are trying to sa= y that in future when you add a new security mechanism ensure that it also = has the provision to encrypt in addition to verifying the integrity of the = routing packets. So while we have removed this from the -04 version, this can be added in -0= 5, if the WG feels that it ought to be captured somewhere. Cheers, Manav From uma.chunduri@ericsson.com Sat Mar 17 16:31:18 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3859E21F864A for ; Sat, 17 Mar 2012 16:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjqjT43L0urY for ; Sat, 17 Mar 2012 16:31:17 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 36A3621F8537 for ; Sat, 17 Mar 2012 16:31:17 -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 q2HNVEuR023593; Sat, 17 Mar 2012 18:31:15 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.140]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sat, 17 Mar 2012 19:31:08 -0400 From: Uma Chunduri To: "Bhatia, Manav (Manav)" , "karp@ietf.org" Date: Sat, 17 Mar 2012 19:31:07 -0400 Thread-Topic: requirement 17 from karp-threat-reqs-03 Thread-Index: Ac0EDoGNOROIHCrTRiKfL8rdXs8PwQAhgbDw Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D02DB3D29@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02DB3D29@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 Subject: Re: [karp] requirement 17 from karp-threat-reqs-03 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 23:31:18 -0000 "The authentication mechanism does not provide message confidentiality, but= SHOULD NOT preclude the possibility of confidentiality support being added= in the future." The above text has been removed in the latest version and we would like to = solicit comments from the WG members on this issue. At the first glance the requirement seems to be absurd because an "authenti= cation mechanism" cannot by definition provide confidentiality.=20 This is definitely absurd and confidentiality for routing protocol messages= is bit red herring (out of KARP scope, I would say). So while we have removed this from the -04 version, this can be added in -0= 5, if the WG feels that it ought to be captured somewhere. It's good this has been removed and I don't think it should be captured som= ewhere. -- Uma C. From mjethanandani@gmail.com Mon Mar 19 13:32:55 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA97921E803A for ; Mon, 19 Mar 2012 13:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVyu7BoJGNe5 for ; Mon, 19 Mar 2012 13:32:55 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 425C221E8036 for ; Mon, 19 Mar 2012 13:32:55 -0700 (PDT) Received: by dakl33 with SMTP id l33so11555667dak.31 for ; Mon, 19 Mar 2012 13:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=dOpCVnVDrlTG/Dg1WUjZEK8dubhy+ysvsFPV4/256Kk=; b=E6QEcqh2dElMBWMNihOyrCeFtA8toRPt3lB2REMC0EcB+HTDm9QBoOhu9+6A5H2tUa b8uGV0FC4pSPbUH5tmRvlcmy/zfurPobv+w+4NRYgwlkm5DkC7Bka8/aZUzxc2MTy1kk rwXEAYIHpzPHv4c4ozoPxgKx9+z9oQlyOWIiQz1B1w7Ew2B8UOZmsP3Sq5PmHyB0k41Y xaHBzIdWu6/adjuHA1z8U2GmC+g7bRbKvgP90dV+2Jsv/vvikI6PkyoyJx1lzD+vZDMA wup4CLwgeLDBk5PiRziDNTDa8CmbeVWcp/jxxlgiNsxb+zHwvNL70lUhb35cF8fKN54p OCYQ== Received: by 10.68.135.74 with SMTP id pq10mr44219686pbb.24.1332189174945; Mon, 19 Mar 2012 13:32:54 -0700 (PDT) Received: from [192.168.1.123] (c-24-6-173-225.hsd1.ca.comcast.net. [24.6.173.225]) by mx.google.com with ESMTPS id z1sm12047500pbc.38.2012.03.19.13.32.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 13:32:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-9--452830408 From: Mahesh Jethanandani In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02DB3D29@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 19 Mar 2012 13:32:51 -0700 Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350D02DB3D29@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1084) Cc: "karp@ietf.org" Subject: Re: [karp] requirement 17 from karp-threat-reqs-03 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 20:32:56 -0000 --Apple-Mail-9--452830408 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Manav, Another way to look at this would be to see where the need is coming = from. Do we know? One of the reasons I have heard is to keep the internal topology of the = network private. How important is this requirement? On Mar 17, 2012, at 12:21 AM, Bhatia, Manav (Manav) wrote: > "The authentication mechanism does not provide message = confidentiality, but SHOULD NOT preclude the possibility of = confidentiality support being added in the future." Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail-9--452830408 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
"The = authentication mechanism does not provide message confidentiality, but = SHOULD NOT preclude the possibility of confidentiality support being = added in the future."

Mahesh = Jethanandani
<= div>


= --Apple-Mail-9--452830408-- From russw@riw.us Tue Mar 20 19:14:19 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1BE21E801C for ; Tue, 20 Mar 2012 19:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER0PdJJwsV-R for ; Tue, 20 Mar 2012 19:14:18 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5596421E801A for ; Tue, 20 Mar 2012 19:14:17 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:53160 helo=[192.168.100.63]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SAB42-000797-JI for karp@ietf.org; Tue, 20 Mar 2012 22:14:14 -0400 Message-ID: <4F693974.7050403@riw.us> Date: Tue, 20 Mar 2012 22:14:12 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: karp@ietf.org References: <7C362EEF9C7896468B36C9B79200D8350D02DB3D29@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02DB3D29@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [karp] requirement 17 from karp-threat-reqs-03 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 02:14:19 -0000 > However, the bigger question is, that do we even want to keep this requirement? Do we envisage a scenario in future where we might want to encrypt the routing packets? If not, then we can safely remove this requirement. The reason this text was added was because certain people felt that we ought to address confidentiality (and not just message integrity) of the routing packets. The result of that discussion was this text where we are trying to say that in future when you add a new security mechanism ensure that it also has the provision to encrypt in addition to verifying the integrity of the routing packets. I wouldn't keep it... I don't know of any requirement for keeping the topology hidden on a link that can otherwise be easily compromised. If this type of security is required, it should be provided at a lower layer, IMHO. :-) Russ From manav.bhatia@alcatel-lucent.com Wed Mar 21 04:14:01 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE9721F84EE for ; Wed, 21 Mar 2012 04:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.756 X-Spam-Level: X-Spam-Status: No, score=-6.756 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-zX6ZniV22o for ; Wed, 21 Mar 2012 04:14:00 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5138021F84D7 for ; Wed, 21 Mar 2012 04:13:59 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q2LBDVbr012095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 21 Mar 2012 06:13:53 -0500 (CDT) 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 q2LBDU6C009538 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 21 Mar 2012 16:43:30 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 21 Mar 2012 16:43:30 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Wed, 21 Mar 2012 16:43:45 +0530 Thread-Topic: Karp-threat-reqs Updated Thread-Index: Ac0HU66bfZthpHDJQDCYTPt/cTJoIw== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02DB4518@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.39 Subject: [karp] Karp-threat-reqs Updated X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 11:14:01 -0000 Hi, Gregory and I have updated the karp-threat-reqs (with lot of help from Bria= n) based on the IETF LC and the extensive Sec Dir review comments that we r= eceived. Please let us know if you think a few comments have been left unad= dressed. You can easily view the differences from the last version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-threats-reqs-04.txt Cheers, Manav From touch@isi.edu Wed Mar 21 11:29:12 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8884721E8064 for ; Wed, 21 Mar 2012 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.82 X-Spam-Level: X-Spam-Status: No, score=-102.82 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvC+eE5jNezR for ; Wed, 21 Mar 2012 11:29:12 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5A021E8063 for ; Wed, 21 Mar 2012 11:29:12 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q2LISa1L017078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Mar 2012 11:28:38 -0700 (PDT) Message-ID: <4F6A1DD4.1020904@isi.edu> Date: Wed, 21 Mar 2012 11:28:36 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <7C362EEF9C7896468B36C9B79200D8350D02DB4518@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02DB4518@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "karp@ietf.org" Subject: Re: [karp] Karp-threat-reqs Updated X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 18:29:12 -0000 Some comments and questions below. Joe ---- Current Sec 2.2 (incremental approach) The last sentence (which is repeated) appears to raise issues with TCP-AO, but the concerns are already addressed in TCP-AO's design - AO already prevents replay attacks, allows TCP connections to restart without the need to install new keys at the endpoints, and supports different crypto algorithms. What are the concerns here? ---- Current Sec 4, requirement 5 You state that routing protocols need to be able to detect and reject replayed messages. IMO, they need to be protected against such replays, but it can be sufficient for a transport (e.g., TCP-AO) or network (e.g., IPsec) mechanism to provide that protection. If they are NOT protected by other layers, then the protection needs to be inside the routing protocol. Is that what you meant, or is there some reason for needing this in the routing protocol itself? ----- On 3/21/2012 4:13 AM, Bhatia, Manav (Manav) wrote: > Hi, > > Gregory and I have updated the karp-threat-reqs (with lot of help from Brian) based on the IETF LC and the extensive Sec Dir review comments that we received. Please let us know if you think a few comments have been left unaddressed. > > You can easily view the differences from the last version: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-karp-threats-reqs-04.txt > > Cheers, Manav > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From manav.bhatia@alcatel-lucent.com Wed Mar 21 19:10:58 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3028521E8047 for ; Wed, 21 Mar 2012 19:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.75 X-Spam-Level: X-Spam-Status: No, score=-6.75 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB5Yocw59n96 for ; Wed, 21 Mar 2012 19:10:57 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD9B21E8032 for ; Wed, 21 Mar 2012 19:10:57 -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 q2M2ArhY018216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Mar 2012 21:10:56 -0500 (CDT) 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 q2M2Aq29009792 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 22 Mar 2012 07:40:52 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 22 Mar 2012 07:40:52 +0530 From: "Bhatia, Manav (Manav)" To: Joe Touch Date: Thu, 22 Mar 2012 07:41:05 +0530 Thread-Topic: [karp] Karp-threat-reqs Updated Thread-Index: Ac0HkIVbeMYAQAeQRR2XfcPPYwgxLwAQDvsw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02DB45E6@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02DB4518@INBANSXCHMBSA1.in.alcatel-lucent.com> <4F6A1DD4.1020904@isi.edu> In-Reply-To: <4F6A1DD4.1020904@isi.edu> 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 Cc: "karp@ietf.org" Subject: Re: [karp] Karp-threat-reqs Updated X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 02:10:58 -0000 >=20 > Current Sec 4, requirement 5 >=20 > You state that routing protocols need to be able to detect=20 > and reject replayed messages. >=20 > IMO, they need to be protected against such replays, but it=20 > can be sufficient for a transport (e.g., TCP-AO) or network=20 > (e.g., IPsec) mechanism to provide that protection. If they=20 > are NOT protected by other layers, then the protection needs=20 > to be inside the routing protocol. >=20 > Is that what you meant, or is there some reason for needing=20 > this in the routing protocol itself? Yes, that's what we had meant. The authentication mechanism that the routin= g protocol employs (it could either be inband to the routing protocol or co= uld be a function of the transport layer) must be able to detect and reject= replayed messages. I'll let Gregory address your other comment on TCP-AO. Cheers, Manav=20 From touch@isi.edu Wed Mar 21 22:04:34 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3646521E804B for ; Wed, 21 Mar 2012 22:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.928 X-Spam-Level: X-Spam-Status: No, score=-102.928 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gjYSTEkJvEb for ; Wed, 21 Mar 2012 22:04:33 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A967121E8027 for ; Wed, 21 Mar 2012 22:04:33 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q2M54C7n007750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Mar 2012 22:04:15 -0700 (PDT) Message-ID: <4F6AB2CC.2040900@isi.edu> Date: Wed, 21 Mar 2012 22:04:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <7C362EEF9C7896468B36C9B79200D8350D02DB4518@INBANSXCHMBSA1.in.alcatel-lucent.com> <4F6A1DD4.1020904@isi.edu> <7C362EEF9C7896468B36C9B79200D8350D02DB45E6@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02DB45E6@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "karp@ietf.org" Subject: Re: [karp] Karp-threat-reqs Updated X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 05:04:34 -0000 On 3/21/2012 7:11 PM, Bhatia, Manav (Manav) wrote: >> >> Current Sec 4, requirement 5 >> >> You state that routing protocols need to be able to detect >> and reject replayed messages. >> >> IMO, they need to be protected against such replays, but it >> can be sufficient for a transport (e.g., TCP-AO) or network >> (e.g., IPsec) mechanism to provide that protection. If they >> are NOT protected by other layers, then the protection needs >> to be inside the routing protocol. >> >> Is that what you meant, or is there some reason for needing >> this in the routing protocol itself? > > Yes, that's what we had meant. The authentication mechanism that the routing protocol employs (it could either be inband to the routing protocol or could be a function of the transport layer) must be able to detect and reject replayed messages. AOK - it might be useful to clarify that in the next rev. Joe > I'll let Gregory address your other comment on TCP-AO. > > Cheers, Manav From bew@cisco.com Thu Mar 22 14:01:36 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F5721E8037 for ; Thu, 22 Mar 2012 14:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfjoUUVzcb+A for ; Thu, 22 Mar 2012 14:01:35 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4430621E802B for ; Thu, 22 Mar 2012 14:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=729; q=dns/txt; s=iport; t=1332450095; x=1333659695; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=BiAZGec0Ajnb7LhFt/Z1h5nSBj/YzfEqahcoT6INqbs=; b=J1t0Woc5zRMek0yF3taHNHF8hUKZZ8OXLk1zz0a8FbR0rIQDvJE2XgGO 2MD7wpp06oJ10sR076nkjoudmH4AwPLX4BV1Rk7pNIw3CsXCB0m+443ZY Qg+PJWuOBZnlcEtaEX7Q9CXNxOBq8Dia5FEdf5zv2V4MBczAgNkeUBRn4 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEALqSa0+rRDoI/2dsb2JhbABEtz2BB4IiASeCModnAQuXfYEnnxCNQoI/YwSIVo0JjkCBaIMHgTw X-IronPort-AV: E=Sophos;i="4.73,632,1325462400"; d="scan'208";a="34711786" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 22 Mar 2012 21:01:35 +0000 Received: from dhcp-128-107-147-81.cisco.com (dhcp-128-107-147-81.cisco.com [128.107.147.81]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2ML1ZYh000479 for ; Thu, 22 Mar 2012 21:01:35 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Mar 2012 14:01:33 -0700 Message-Id: To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [karp] Re-review of draft-ietf-karp-threats-reqs-04 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 21:01:36 -0000 Greetings KARP participants, The karp-threat-reqs-03 I-D completed its IETF Last Call period and the = authors have produced a new draft addressing LC comments. The changes = are extensive, and you can review them by clicking on the link in = Manav's recent email, or the one below. This is a fundamental draft that = guides the KARP work, and we ask that you carefully review the changes = to the -04 draft before it is progressed. Please post questions and = comments to this list prior to April 12th, at which time we will = consider the review period closed and will determine what is the next = step. = = Thanks, Joel & Brian= From gregory.ietf@gmail.com Fri Mar 23 10:12:31 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2811E21F8602 for ; Fri, 23 Mar 2012 10:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUwx9tvZUzTR for ; Fri, 23 Mar 2012 10:12:27 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E65FC21F85FF for ; Fri, 23 Mar 2012 10:12:26 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2889855pbb.31 for ; Fri, 23 Mar 2012 10:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wHocDJFktDKdJhwIMwodsW1xGHcMWVb7IfPEYSOxFSY=; b=Z7/Mqf7v27zfYniaKZUglCf26jPSh8mEAibrPc5+DCGpqdL4AiqbApfsQFUe8K/mIj FBRjwZRv3KfAnd+bjHE0+QlzcHUplHkBV+fDyORKIReT2iKrcSA1oAy/IzjrvEdfvgy6 ZAM21NJeQn1SaPNA4sr2/Di9GjUvAkz40s6QINMFHCX4lImSXEPt2w2zmUXK9M56rZHz ZYZTdXx0REYLXjSgfQcAStbHdEEwPjiYesQdl14z1GuuH9KG6QthqKy3UgulK04hepdh g5kphwMktFmk20E1FDptf9hKE5NZPXo51QCb07NBcq3VknTtvD2i3xfeHNPNmzx9qcSE 8kUQ== MIME-Version: 1.0 Received: by 10.68.135.38 with SMTP id pp6mr30580292pbb.82.1332522746690; Fri, 23 Mar 2012 10:12:26 -0700 (PDT) Received: by 10.68.129.73 with HTTP; Fri, 23 Mar 2012 10:12:26 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02DB3D29@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D02DB3D29@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Fri, 23 Mar 2012 10:12:26 -0700 Message-ID: From: Gregory Lebovitz To: "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=047d7b10c899f8bd2604bbec2049 Cc: "karp@ietf.org" Subject: Re: [karp] requirement 17 from karp-threat-reqs-03 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:12:31 -0000 --047d7b10c899f8bd2604bbec2049 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 17, 2012 at 12:21 AM, Bhatia, Manav (Manav) < manav.bhatia@alcatel-lucent.com> wrote: --SNIP-- > > At the first glance the requirement seems to be absurd because an > "authentication mechanism" cannot by definition provide confidentiality. > This can be fixed by tweaking the text to say that the new security > mechanism should provide message integrity in addition to being able to > support confidentiality if required. > One issue with "a new security mechanism should provide message integrity in addition to being able to support confidentiality if required" is that it would be out of scope of the WG, as currently chartered. The original requirement was compromise text for the pro-encryption crowd. It was intended to say, "we are going to focus on message integrity, but someone may, in the future, want to charter work to do message confidentiality. Keep that in mind and don't do anything that would PRECLUDE adding message confidentiality later." Such a requirement, though appearing extremely wise and considerate at first glance, is very difficult to fulfill in actuality. How do we design to not conflict with a message confidentiality mechanism that we have not yet created? We would essentially need to complete design of the "future" message confidentiality mechanism before we complete the message integrity in order to fulfill the requirement. Such is both out of scope, and not practical. > > However, the bigger question is, that do we even want to keep this > requirement? Do we envisage a scenario in future where we might want to > encrypt the routing packets? >From my above comment, I hope I have made a strong case that whether or not we may want encryption in the future is not the question. The question is one of scope and practical execution. Can the requirement actually be accomplished while staying in scope in a reasonable amount of time? > If not, then we can safely remove this requirement. The reason this text > was added was because certain people felt that we ought to address > confidentiality (and not just message integrity) of the routing packets. > The result of that discussion was this text where we are trying to say that > in future when you add a new security mechanism ensure that it also has the > provision to encrypt in addition to verifying the integrity of the routing > packets. > > So while we have removed this from the -04 version, this can be added in > -05, if the WG feels that it ought to be captured somewhere. > I would be comfortable adding it back in if someone could demonstrate a high probability of fulfilling the requirement while staying in scope. I would assume the text would be very different in order to communicate this strong probability and keeping in scope. To date, I have not seen this. Gregory > > Cheers, Manav > > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --047d7b10c899f8bd2604bbec2049 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Mar 17, 2012 at 12:21 AM, Bhatia, Ma= nav (Manav) <manav.bhatia@alcatel-lucent.com> wrote:
--SNIP--

At the first glance the requirement seems to be absurd because an "aut= hentication mechanism" cannot by definition provide confidentiality. T= his can be fixed by tweaking the text to say that the new security mechanis= m should provide message integrity in addition to being able to support con= fidentiality if required.

One issue with "a new security mechan= ism should provide message integrity in addition to being able to support c= onfidentiality if required" is that it would be out of scope of the WG= , as currently chartered.=A0

The original requirement was compromise text for the pr= o-encryption crowd. It was intended to say, "we are going to focus on = message integrity, but someone may, in the future, want to charter work to = do message confidentiality. Keep that in mind and don't do anything tha= t would PRECLUDE adding message confidentiality later." Such a require= ment, though appearing extremely wise and considerate at first glance, is v= ery difficult to fulfill in actuality. How do we design to not conflict wit= h a message confidentiality mechanism that we have not yet created? We woul= d essentially need to complete design of the "future" message con= fidentiality mechanism before we complete the message integrity in order to= fulfill the requirement. Such is both out of scope, and not practical.

=A0

However, the bigger question is, that do we even want to keep this requirem= ent? Do we envisage a scenario in future where we might want to encrypt the= routing packets?

From my above comment, I = hope I have made a strong case that whether or not we may want encryption i= n the future is not the question. The question is one of scope and practica= l execution. Can the requirement actually be accomplished while staying in = scope in a reasonable amount of time?
=A0
If not, then we can safely re= move this requirement. The reason this text was added was because certain p= eople felt that we ought to address confidentiality (and not just message i= ntegrity) of the routing packets. The result of that discussion was this te= xt where we are trying to say that in future when you add a new security me= chanism ensure that it also has the provision to encrypt in addition to ver= ifying the integrity of the routing packets.

So while we have removed this from the -04 version, this can be added in -0= 5, if the WG feels that it ought to be captured somewhere.
=

I would be comfortable adding it back in if someone cou= ld demonstrate a high probability of fulfilling the requirement while stayi= ng in scope. I would assume the text would be very different in order to co= mmunicate this strong probability and keeping in scope. To date, I have not= seen this.

Gregory=A0
=A0

Cheers, Manav



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



--
----
IETF= related email from
Gregory M. Lebovitz
Juniper Networks
--047d7b10c899f8bd2604bbec2049-- From gregory.ietf@gmail.com Fri Mar 23 10:18:35 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634CB21F8606 for ; Fri, 23 Mar 2012 10:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4a92Z2Gzg0c for ; Fri, 23 Mar 2012 10:18:31 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3293521F8604 for ; Fri, 23 Mar 2012 10:18:31 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3280423ggm.31 for ; Fri, 23 Mar 2012 10:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4f4Pe4D/UF5a5Wx2Ga3nQ540qsqTjit05IgrmUnxZ+g=; b=XzjLHpJgcccHJQ4EmFLkPypBcRc8S91f3PhjpR0o07uAZ7GsNgHv39ECXE+3fgPxfk HHrvgRJ0UyuL4qBCAcA4vIH2IsbZ24rEm5/m/hBRiWlD46EMhEaYJJd2nqjVY3W4DI2U iJvDFbn1kprz3dpqHhrz6Z5IQgp2JHiVCqJoeA4Ky4Mta2i9tWM873L9/E/UXyXtKQGM tE6VE65c5czN9EYqCmP1OoUy1JkGdySslEw4Km6+OtWuqhvFcipPGXnKG1TH5mOaoKYK W+yJezFi/NbkzfL44gnxzpcYxiB2WffVKhcpM4t3xcMGfqWltxEhmGkEmuLSZRC7kF4R rxuw== MIME-Version: 1.0 Received: by 10.68.223.193 with SMTP id qw1mr30819149pbc.61.1332523110412; Fri, 23 Mar 2012 10:18:30 -0700 (PDT) Received: by 10.68.129.73 with HTTP; Fri, 23 Mar 2012 10:18:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Mar 2012 10:18:30 -0700 Message-ID: From: Gregory Lebovitz To: Uma Chunduri Content-Type: multipart/alternative; boundary=047d7b160597a6b0cc04bbec3601 Cc: Sam Hartman , "karp@ietf.org" Subject: [karp] threats-reqs: New requirements document for KMP X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:18:35 -0000 --047d7b160597a6b0cc04bbec3601 Content-Type: text/plain; charset=ISO-8859-1 Quick point of order on Uma's comment: it's a different subject than this thread's original subject. Uma, would you mind starting a new thread with the below and Sam's response? This would leave the current thread focused on the parenthetical text about KMP in the threat-reqs document. Thanks, Gregory On Thu, Mar 15, 2012 at 3:01 PM, Uma Chunduri wrote: > Hi Sam, > > >>>I think there are aspects of the KMP discussion where we do better > need to understand the requirements. > >>>For example, I don't think we have a good view about how KMP > interacts with RP surrounding issues > >>>like TCP-AO's state, the key tables draft, etc. It's quite clear > that Joe Touch and I have different > >>>ideas on some of this as an example. I think we should have those > discussions. I think some consensus > >>>calls will need to be made even. > > For your particular comment above, I see you are talking about TCP-based > RPs interaction. > We updated the AO-KMP document with Gatekeeper module presented in Taipei. > Could you spell > specific differences you have on this? > > -- > Uma C. > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --047d7b160597a6b0cc04bbec3601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Quick point of order on Uma's comment: =A0it's a different subject = than this thread's original subject.=A0

Uma, would y= ou mind starting a new thread with the below and Sam's response? This w= ould leave the current thread focused on the parenthetical text about KMP i= n the threat-reqs document.=A0

Thanks,
Gregory

On Thu, Mar 15, 2012 at 3:01 PM, Uma Chunduri <uma.chunduri@ericsson.com>= ; wrote:
Hi Sam,

=A0 =A0>>>I think there are aspects of the KMP discussion where w= e do better need to understand the requirements.
=A0 =A0>>>For example, I don't think we have a good view abou= t how KMP interacts with RP surrounding issues
=A0 =A0>>>like TCP-AO's state, the key tables draft, etc. It&= #39;s quite clear that Joe Touch and I have different
=A0 =A0>>>ideas on some of this as an example. =A0I think we shou= ld have those discussions. I think some consensus
=A0 =A0>>>calls will need to be made even.

For your particular comment above, I see you are talking about TCP-ba= sed RPs interaction.
We updated the AO-KMP document with Gatekeeper module presented in Taipei. = Could you spell
specific differences you have on this?

--
Uma C.

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



--
= ----
IETF related email from
Gregory M. Lebovitz
Juniper Networks<= br>
--047d7b160597a6b0cc04bbec3601-- From gregory.ietf@gmail.com Fri Mar 23 10:26:49 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C8421F8611 for ; Fri, 23 Mar 2012 10:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-5ngM78P1KT for ; Fri, 23 Mar 2012 10:26:45 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D69221F85C4 for ; Fri, 23 Mar 2012 10:26:45 -0700 (PDT) Received: by yenm5 with SMTP id m5so3274630yen.31 for ; Fri, 23 Mar 2012 10:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BGck0eM44pIN+asRJYpIdmRm11dbaXJtgQn5OjZDP40=; b=0NF6ejI2te52SFsZtvh+A9eEd1YYOjaXra8VP6InL8Ov8QCyQCGbUu4bE/zBOou0Qs oIkR9ErWCPJ839DeiFtAK6UkfpZFw4G8OT9nCd+WUgOoUEE0hRy3wooZmvx4co1esquD AGwsvkl+WVY7OeUeTE17cXLWbHGtikGch1I7AyFgau9MCmhbe8GNFBPaZrpcK7e3VDJJ q26KVZZgK4JLIT21vXH8A7ZTgzGTZJTF/eOHAr5V69eC/tus1ctMBq15TXH7ZeMO4xjr QC/YnU8WHBoHI+TqnCO5cstqKEuCU1/3N7L30eeNFwxPdMrNDt22Yc/mBSs6FfhT0tLJ mOpg== MIME-Version: 1.0 Received: by 10.68.72.9 with SMTP id z9mr31327572pbu.124.1332523604356; Fri, 23 Mar 2012 10:26:44 -0700 (PDT) Received: by 10.68.129.73 with HTTP; Fri, 23 Mar 2012 10:26:44 -0700 (PDT) In-Reply-To: References: <6EFEEA85-1E82-4592-A258-E350F5F8D45D@cisco.com> Date: Fri, 23 Mar 2012 10:26:44 -0700 Message-ID: From: Gregory Lebovitz To: Sam Hartman Content-Type: multipart/alternative; boundary=f46d0417019117ae7704bbec5497 Cc: karp@ietf.org Subject: Re: [karp] threats-reqs: New requirements document for KMP X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:26:49 -0000 --f46d0417019117ae7704bbec5497 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 15, 2012 at 2:26 PM, Sam Hartman wrote: > >>>>> "Brian" == Brian Weis writes: > > Brian> Hi Sam, Thanks for your review. This is new text responding > Brian> to a reviewer comment pointing out that this document only > Brian> covers "PHASE 1" of the KARP Design Guide (RFC 6518). I > Brian> believe the main contribution of the new text is to declare > Brian> that "PHASE 2" is not being addressed in this I-D. The text > Brian> you are objecting to is parenthetical text promising another > Brian> requirements document. I propose removing this text and > Brian> discussing the need for another requirements document > Brian> independently. > > I support that proposal. > GL> +1. GL> How's this for replacement text: GL> CURRENT: GL> "Work Phase 2", a framework and usage of a KMP, will be GL> addressed in a future requirements document." GL> NEW: GL> "Work Phase 2", a framework and usage of a KMP, GL> will be addressed in a future document(s)." GL> GL> This would occur in both the introduction and the 1st GL> paragraph of section 4. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > -- ---- IETF related email from Gregory M. Lebovitz --f46d0417019117ae7704bbec5497 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2012 at 2:26 PM, Sam Hartman <hartmans-ietf@mit.edu> wrot= e:
>>>>> "Brian" =3D=3D Brian Weis <bew@cisco.com> writes:

=A0 =A0Brian> Hi Sam, Thanks for your review. This is new text respondi= ng
=A0 =A0Brian> to a reviewer comment pointing out that this document onl= y
=A0 =A0Brian> covers "PHASE 1" of the KARP Design Guide (RFC = 6518). I
=A0 =A0Brian> believe the main contribution of the new text is to decla= re
=A0 =A0Brian> that "PHASE 2" is not being addressed in this I= -D. The text
=A0 =A0Brian> you are objecting to is parenthetical text promising anot= her
=A0 =A0Brian> requirements document. I propose removing this text and =A0 =A0Brian> discussing the need for another requirements document
=A0 =A0Brian> independently.

I support that proposal.

GL> +1.=A0<= /div>
GL> How's this for replacement text:
GL> CURR= ENT:
GL> "Work Phase 2", a framework and usage of a KMP, will be=A0=

GL> addressed in a future requirements document."
GL> NEW: =A0
GL> "Work Phase 2", a framework and usage of a KMP,=A0
GL> will be addressed in a future document(s)."
GL>
GL> This would occur in both the introduction and the 1st
GL> paragraph of section 4.
=A0
___________________________________= ____________
karp mailing list
karp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/karp



--
= ----
IETF related email from
Gregory M. Lebovitz
--f46d0417019117ae7704bbec5497-- From gregory.ietf@gmail.com Fri Mar 23 10:52:32 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23DC21F864A for ; Fri, 23 Mar 2012 10:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.071 X-Spam-Level: X-Spam-Status: No, score=-103.071 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV0bki2ZwA+V for ; Fri, 23 Mar 2012 10:52:26 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F45B21F8649 for ; Fri, 23 Mar 2012 10:52:26 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3312335ggm.31 for ; Fri, 23 Mar 2012 10:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=iL69KostWVO5FO4NpuSoUyhKN+4ibdiTaU1webRT1aE=; b=A++nTp/tHrUCzs6ZSUuAArixHH1n1jA8i6SUGqK5f7IsYhA+KJDNOxcQZ9qA6on/2w ttrG4TslNkkkcFPMRGnSSXmZJaFxnHXMeiQmvZUNOru4mPZh+8WhjUwNHVQg0nzE/3pX pqNK5G9R2+CTcYKV2FvlcLCYonQmk1QE3VEEkkqLUvLfBI4nBOJXN+y22969ElXuAvZd YhKbivOXKhPsbqiJPFp2zIctWe7FZMJH3OMe4D3bHoTHq+foVYWQlQIHgL9QYMaHaE4q Mz79J2eNafNJhF/WGYN3E82ZVMstNB58ydolar+eoI5nfIlWH92QTaposhiaDr940GlY BXaA== MIME-Version: 1.0 Received: by 10.68.135.38 with SMTP id pp6mr30846302pbb.82.1332525145516; Fri, 23 Mar 2012 10:52:25 -0700 (PDT) Received: by 10.68.129.73 with HTTP; Fri, 23 Mar 2012 10:52:25 -0700 (PDT) Date: Fri, 23 Mar 2012 10:52:25 -0700 Message-ID: From: Gregory Lebovitz To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b10c899f3e87e04bbecaf4c Cc: "karp@ietf.org" Subject: [karp] Karp-threat-reqs 2.2, tcp-ao comments (was "Karp-threat-reqs Updated") X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:52:32 -0000 --047d7b10c899f3e87e04bbecaf4c Content-Type: text/plain; charset=ISO-8859-1 thread subject was: Karp-threat-reqs Updated Specifying to: "Karp-threat-reqs 2.2 & tcp-ao comments" On Wed, Mar 21, 2012 at 11:28 AM, Joe Touch wrote: > Some comments and questions below. > > Joe > > ---- > > Current Sec 2.2 (incremental approach) > > The last sentence (which is repeated) appears to raise issues with TCP-AO, > but the concerns are already addressed in TCP-AO's design - AO already > prevents replay attacks, allows TCP connections to restart without the need > to install new keys at the endpoints, and supports different crypto > algorithms. > > What are the concerns here? > Good catch, Joe. This is text rot from when we first started this draft years ago, and were right in the middle of the -AO effort together. It should only be an example of how we took an incremental approach. How is this for replacement text: Last, some security mechanisms require the build out of other operational support systems, and this will take time. An example where these three reasons were at play in an incremental improvement roadmap was seen in the improvement of BGP's [RFC4271 ] security via the TCP Authentication Option (TCP-AO) [RFC5925 ] effort. It would have been ideal, and reflect best common security practice, to have a fully specified key management protocol for negotiating TCP-AO's keying material, e.g., using certificates for peer authentication. However,in the spirit of incremental deployment, we first addressed issues like cryptographic algorithm agility, replay attacks, TCP session resetting in the base TCP-AO protocol, and then later layered key management on top of it. ? -- ---- IETF related email from Gregory M. Lebovitz --047d7b10c899f3e87e04bbecaf4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable thread subject was:=A0Karp-threat-reqs Updated
Specifying to: "Karp-threat-reqs 2.2 & tcp-ao comments"= ;

On Wed, Mar 21, 2012 at 11:28 AM, Joe Touch = <to= uch@isi.edu> wrote:
Some comments and questions below.

Joe

----

Current Sec 2.2 (incremental approach)

The last sentence (which is repeated) appears to raise issues with TCP-AO, = but the concerns are already addressed in TCP-AO's design - AO already = prevents replay attacks, allows TCP connections to restart without the need= to install new keys at the endpoints, and supports different crypto algori= thms.

What are the concerns here?

Good catch,= Joe. This is text rot from when we first started this draft years ago, and= were right in the middle of the -AO effort together. It should only be an = example of how we took an incremental approach. How is this for replacement= text:

-- <= br>----
IETF related email from
Gregory M. Lebovitz
--047d7b10c899f3e87e04bbecaf4c-- From jmh@joelhalpern.com Mon Mar 26 00:52:44 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1556621F851B for ; Mon, 26 Mar 2012 00:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.335 X-Spam-Level: X-Spam-Status: No, score=-101.335 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D49G2vyWgtNR for ; Mon, 26 Mar 2012 00:52:43 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7F45721F8516 for ; Mon, 26 Mar 2012 00:52:40 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 236FF55822B for ; Mon, 26 Mar 2012 00:52:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D2CB21BCA113 for ; Mon, 26 Mar 2012 00:52:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [130.129.38.181] (dhcp-26b5.meeting.ietf.org [130.129.38.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7532B1BCA110 for ; Mon, 26 Mar 2012 00:52:39 -0700 (PDT) Message-ID: <4F702048.4060707@joelhalpern.com> Date: Mon, 26 Mar 2012 03:52:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "karp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] scribes? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 07:52:44 -0000 We do need a minute taker, and preferably a jabber scribe, for the meeting. Anyone willing to step forward? Otherwise, we will all have to sit there at the start of the meeting waiting for someone to feel guilty enough to do so. We can not start without a scribe. Thank you, Joel M. halpern From internet-drafts@ietf.org Mon Mar 26 09:15:17 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E31621E80FF; Mon, 26 Mar 2012 09:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ch0I0KUrb4u; Mon, 26 Mar 2012 09:15:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F4021E8097; Mon, 26 Mar 2012 09:15:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326161516.27054.71100.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 09:15:16 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:15:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing= Protocols Working Group of the IETF. Title : Analysis of BGP, LDP, PCEP, and MSDP Security According = to KARP Design Guide Author(s) : Mahesh Jethanandani Keyur Patel Lianshu Zheng Filename : draft-ietf-karp-routing-tcp-analysis-01.txt Pages : 17 Date : 2012-03-26 This document analyzes BGP, LDP, PCEP and MSDP according to guidelines set forth in section 4.2 of Keying and Authentication for Routing Protocols Design Guidelines [RFC6518]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-routing-tcp-analysis-01= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-routing-tcp-analysis-01.= txt From touch@isi.edu Tue Mar 27 07:19:53 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E7D21E8094 for ; Tue, 27 Mar 2012 07:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.11 X-Spam-Level: X-Spam-Status: No, score=-103.11 tagged_above=-999 required=5 tests=[AWL=-0.738, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHD1GROhq4lw for ; Tue, 27 Mar 2012 07:19:52 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 82B5421E8091 for ; Tue, 27 Mar 2012 07:19:52 -0700 (PDT) Received: from [100.44.124.247] ([216.53.135.2]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q2REJAHU012644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Mar 2012 07:19:20 -0700 (PDT) Message-ID: <4F71CC60.4090007@isi.edu> Date: Tue, 27 Mar 2012 07:19:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Gregory Lebovitz References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "karp@ietf.org" Subject: Re: [karp] Karp-threat-reqs 2.2, tcp-ao comments (was "Karp-threat-reqs Updated") X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:19:53 -0000 Hi, Gregory, On 3/23/2012 10:52 AM, Gregory Lebovitz wrote: > thread subject was: Karp-threat-reqs Updated > Specifying to: "Karp-threat-reqs 2.2 & tcp-ao comments" > > On Wed, Mar 21, 2012 at 11:28 AM, Joe Touch > wrote: > > Some comments and questions below. > > Joe > > ---- > > Current Sec 2.2 (incremental approach) > > The last sentence (which is repeated) appears to raise issues with > TCP-AO, but the concerns are already addressed in TCP-AO's design - > AO already prevents replay attacks, allows TCP connections to > restart without the need to install new keys at the endpoints, and > supports different crypto algorithms. > > What are the concerns here? > > > Good catch, Joe. This is text rot from when we first started this draft > years ago, and were right in the middle of the -AO effort together. It > should only be an example of how we took an incremental approach. How is > this for replacement text: > > Last, some security mechanisms require the build out of other > operational support systems, and this will take time. An example > where these three reasons were at play in an incremental improvement > roadmap was seen in the improvement of BGP's [RFC4271 ] security via > the TCP Authentication Option (TCP-AO) [RFC5925 > ] effort. It would have been > ideal, and reflect best common security practice, to have a fully > specified key management protocol for negotiating TCP-AO's keying > material, e.g., using certificates for peer authentication. However, in the > spirit of incremental deployment, we first addressed issues > like cryptographic algorithm agility, replay attacks, TCP session > resetting in the base TCP-AO protocol, and then later layered key management > on top of it. I don't think that's accurate; TCP-AO left out keying for a variety of reasons, but incremental deployment wasn't one of them. The reasons, AFAIR, were: 1) TCP's handshake was deemed insufficient to support useful keying due to lack of SYN option space 2) TCP-AO was specified as just the mods to TCP 3) TCP-AO was intended to be independent of the keying mechanism 4) the development of a keying protocol was deemed out of scope for TCPM I.e., it was at best an issue of incremental development of the components of the solution, but incremental *deployment* was not a consideration I ever recall being raised. Joe From touch@isi.edu Tue Mar 27 07:40:48 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5D121E81CC for ; Tue, 27 Mar 2012 07:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.15 X-Spam-Level: X-Spam-Status: No, score=-105.15 tagged_above=-999 required=5 tests=[AWL=1.449, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ek5D1Zr35pC for ; Tue, 27 Mar 2012 07:40:47 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D2D9121E81AB for ; Tue, 27 Mar 2012 07:40:47 -0700 (PDT) Received: from [100.44.124.247] ([216.53.135.2]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q2REdiBS009734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Mar 2012 07:39:54 -0700 (PDT) Message-ID: <4F71D131.1050704@isi.edu> Date: Tue, 27 Mar 2012 07:39:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: karp@ietf.org References: <20120326161516.27054.71100.idtracker@ietfa.amsl.com> In-Reply-To: <20120326161516.27054.71100.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:40:48 -0000 Comments attached below. Joe On 3/26/2012 9:15 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Keying and Authentication for Routing Protocols Working Group of the IETF. > > Title : Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design Guide > Author(s) : Mahesh Jethanandani > Keyur Patel > Lianshu Zheng > Filename : draft-ietf-karp-routing-tcp-analysis-01.txt > Pages : 17 > Date : 2012-03-26 > > This document analyzes BGP, LDP, PCEP and MSDP according to > guidelines set forth in section 4.2 of Keying and Authentication for > Routing Protocols Design Guidelines [RFC6518]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-karp-routing-tcp-analysis-01.txt ---- - the document name and title are misleading - the document structure is misleading in both cases, transport and network vulnerabilities are confused with routing layer vulnerabilities; the doc should be very clear about what layers are being analyzed at each step - TCP MD5 is cited throughout and noted as weak, even though it is obsoleted by TCP-AO. This should be made clear for every routing protocol that still uses TCP MD5 where that is mentioned, i.e., first that TCP MD5 is obsoleted, and second that TCP-AO fixes the issues of note with TCP MD5 already. - Sec 2.2 mentions reasons for not rekeying secure TCP connections i.e., that they would generate a reset, but this is not the case for TCP-AO, nor was it for TCP MD5. When a key is changed in TCP MD5, segments using the old key would have been discarded (as having the wrong key). TCP-AO allows for key overlap. If there is evidence of resets being caused otherwise, a citation is needed. - Sec 2.3.1.2 suggests that TCP MD5 should be updated with SHA1 This is incorrect; the appropriate recommendation is to shift to TCP-AO, which includes SHA1 already. - Sec 4 discusses TCP's vulnerability to attack This would be an appropriate place to cite RFC 4953 as explaining the issues and problems. The recommendations in RFC5961 are relevant ONLY where IPsec or TCP-AO protections are not used, and RFC5961 mechanisms do not protect against replay, spoofing, or other TCP attacks - only some RST attacks. This section should make it very clear that the use of these techniques does not replace the need for network or transport protection, nor are any of its mechanisms needed when such protections are deployed. This section also talks about TCP-AO key rollover; the mechanism for rollover is defined in TCP-AO. What is missing is how the endpoints decide when to rollover and when to stop using an old key. That remains a key management issue. Regarding connectionless resets, TCP-AO's Section 7.7 does address this issue in detail, and makes three requirements assertions to address that case. The discussion of key rollover impact here is inappropriate; TCP-AO already handles that case without resets - or even packet loss. - Security considerations This section makes recommendations that TCP-AO already covers (e.g., key rollover without connection loss -- or even congestion window impact, as well as replay protection). That should be noted. ---- - From kivinen@iki.fi Wed Mar 28 04:12:36 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160D421F8753 for ; Wed, 28 Mar 2012 04:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcKVJbUyPWxm for ; Wed, 28 Mar 2012 04:12:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8645421F8752 for ; Wed, 28 Mar 2012 04:12:32 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2SBCSpq010667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Mar 2012 14:12:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2SBCS9G007098; Wed, 28 Mar 2012 14:12:28 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6qep4N1Ppj" Content-Transfer-Encoding: 7bit Message-ID: <20338.61976.782291.72072@fireball.kivinen.iki.fi> Date: Wed, 28 Mar 2012 14:12:24 +0300 From: Tero Kivinen To: karp@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min X-Mailman-Approved-At: Wed, 28 Mar 2012 04:44:04 -0700 Subject: [karp] FWD from Tero Kivinen: Some comments to draft-ietf-karp-crypto-table X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 11:12:36 -0000 --6qep4N1Ppj Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Better forward this to list too, as I am not sure who is on the draft-ietf-karp-crypto-key-table.all@tools.ietf.org list... --6qep4N1Ppj Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20334.2688.639477.469167@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Tero Kivinen To: draft-ietf-karp-crypto-key-table.all@tools.ietf.org Subject: Some comments to draft-ietf-karp-crypto-table Date: Sat, 24 Mar 2012 19:55:12 +0200 In section 2. Conceptual Database Structure the document says: To accommodate manual key management, then formatting of the fields has been purposefully chosen to allow updates with a plain text editor. but there is ProtocolSpecificInfo which is specified to be: The ProtocolSpecificInfo field contains a variable length binary object with any protocol specific values. which as binary object might not be that easy to edit with plain text editor. ---------------------------------------------------------------------- PeerKeyID For pairwise keys, the PeerKeyID field is a 16 bit integer in hexadecimal provided by the peer. If the peer has not yet provided this value, the PeerKeyID is set to "unknown". For group keying, the PeerKeyID field is set to "group", which easily accommodates group keys generated by a third party. If the protocol associated wit this key uses a keyname instead of ^^^ Typo. ---------------------------------------------------------------------- Protocol The Protocol field identifies a single security protocol where this key may be used to provide cryptographic protection. This protocol establishes a registry for this field; the registry ^^^^^^^^ I think this should be document, not protocol. also specifies the contents of the following field, ProtcolSpecificInfo, for each registered protocol. ---------------------------------------------------------------------- SendNotBefore, SendNotAfter, RcvNotBefore, RcvNotAfter seem to have lots of errors, I assume those are leftover from the text before when it was only NotBefore and NotAfter: SendNotBefore The NotBefore field specifies the earliest date and time in ^^^^^^^^^ SendNotBefore Universal Coordinated Time (UTC) at which this key should be considered for use when sending traffic. The format is YYYYMMDDHHSSZ, where four digits specify the year, two digits specify the month, two digits specify the day, two digits specify the hour, and two digits specify the minute. The "Z" is included as a clear indication that the time is in UTC. I think it should also specify what SS means for, even when it is quite obvious... SendNotAfter The NotAfter field specifies the latest date and time at which ^^^^^^^^ SendNotAfter this key should be considered for use when sending traffic. The format is the same as the NotBefore field. ^^^^^^^^^ SendNotBefore RcvNotBefore The NotBefore field specifies the earliest date and time in ^^^^^^^^^ RcvNotBefore, and I do not think there is need to repeat the format, jut point to SendNotBefore. Universal Coordinated Time (UTC) at which this key should be considered for use when processing received traffic. The format is YYYYMMDDHHSSZ, where four digits specify the year, two digits specify the month, two digits specify the day, two digits specify the hour, and two digits specify the minute. The "Z" is included as a clear indication that the time is in UTC. RcvNotAfter The NotAfter field specifies the latest date and time at which ^^^^^^^^ RcvNotAfter this key should be considered for use when processing received traffic. The format is the same as the NotBefore field. ^^^^^^^^^ SendNotBefore ---------------------------------------------------------------------- In the section 3 there is again issues with NotBefore/NotAfter vs SendNotBefore/SendNotAfter/RcvNotBefore/RcvNotAfter. (6) NotBefore <= T <= NotAfter. This should be (6) SendNotBefore <= T <= SendNotAfter. (2 places). ---------------------------------------------------------------------- In addition, multiple entries with overlapping use periods are expected to be employed to provide orderly key rollover. In these cases, the expectation is that systems will transition to the newest key available. To meet this requirement, this specification recommends supplementing the key selection algorithm with the following differentiation: select the long-lived key specifying the most recent time in the NotBefore field. ^^^^^^^^^ SendNotBefore. ---------------------------------------------------------------------- (5) NotBefore <= T <= NotAfter. Note that the key usage is loosely bound by the times specified in the NotBefore and NotAfter fields. should be (5) RcvNotBefore <= T <= RcvNotAfter. Note that the key usage is loosely bound by the times specified in the RcvNotBefore and RcvNotAfter fields. and (6) NotBefore <= T <= NotAfter. should be (6) RcvNotBefore <= T <= RcvNotAfter. ---------------------------------------------------------------------- In section 4. Operational Considerations the 1st paragraph If usage periods for long-lived keys do not overlap and system clocks are inconsistent, it is possible to construct scenarios where systems cannot agree upon a long-lived key. When installing a series of keys to be used one after the other (sometimes called a key chain), operators should configure the NotAfter field of the preceding key to be several days after the NotBefore field of the subsequent key to ensure that clock skew is not a concern. should point out that you can make so that receiving ends q RcvNotAfter is larger than other ends SendNotAfter and that new key has RecvNotBefore that is earlier than other peers SendNotBefore. ---------------------------------------------------------------------- In this draft (and quite a lot of other drafts I have been reading lately), it has been very annoying when people use references to RFCs as nouns, and expect everybody to remember what RFC is what: It is recognized in [RFC4107] that automated key management is not viable in some situations. The conceptual database specified in this It would be much nicer to read text which said: It is recognized in Guidelines for Cryptographic Key Management ([RFC4107]) that automated key management is not viable in some situations. The conceptual database specified in this -- kivinen@iki.fi --6qep4N1Ppj-- From uma.chunduri@ericsson.com Thu Mar 29 01:50:54 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C9821F88BC; Thu, 29 Mar 2012 01:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETov86ZdMY3j; Thu, 29 Mar 2012 01:50:52 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B087321F88B7; Thu, 29 Mar 2012 01:50:52 -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 q2T8oa74022695; Thu, 29 Mar 2012 03:50:49 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 29 Mar 2012 04:50:40 -0400 From: Uma Chunduri To: "Les Ginsberg (ginsberg)" , "Naiming Shen (naiming)" Date: Thu, 29 Mar 2012 04:50:38 -0400 Thread-Topic: [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYA= Message-ID: References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.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 Cc: Mike Shand , "isis-wg@ietf.org" , "karp@ietf.org" Subject: Re: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:50:54 -0000 [CC'ed KARP too] In the ISIS wg meeting in Paris, we addressed the concerns raised by Les an= d Mike in the mailing list. As asked by chairs we are summarizing here, the points briefly discussed sp= ecifically on the ESN TLV in LSP. - Though, the originator updates the sequence number and floods the same wh= en replay is received, the impact of the replayed LSP in the network *purely* depends on the co= ntent of the replayed packet (this could be fewer TLV22s/222s or ..) and also all the nodes in the are= a/domain could be impacted. - plz note an adversary can potentially do this for any LSP fragment o= f a particular node/any node. - As rightly pointed by Mike, on the 18hrs max age configuration=20 - if a node/card in the network need to be serviced one can't assume a= lways this can be done=20 in this time=20 - Still ISO default MAXAGE (20mins) is seen in the deployments - In this sense as Naiming indicated if this optional TLV protection i= s needed or not=20 could be decided by the operator.=20 --=20 Uma C.=20 -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf = Of Les Ginsberg (ginsberg) Sent: Thursday, October 27, 2011 6:26 PM To: Naiming Shen (naiming) Cc: Mike Shand; isis-wg@ietf.org Subject: Re: [Isis-wg] Question regardingdraft-chunduri-isis-extended-seque= nce-no-tlv-00 Naiming - > -----Original Message----- > From: Naiming Shen (naiming) > Sent: Thursday, October 27, 2011 6:18 PM > To: Les Ginsberg (ginsberg) > Cc: Mike Shand; isis-wg@ietf.org > Subject: Re: [Isis-wg] Question regardingdraft-chunduri-isis-extended- > sequence-no-tlv-00 >=20 >=20 > My opinion is this: >=20 > - We know we need to have this TLV in non-LSP ISIS packets for obvious > reasons I don't think we have consensus on this yet. I have other concerns regardin= g SNPs and IIHs which I have not yet raised as I thought it would be easier= to discuss one PDU at a time. :-) I also think Manav has raised an excellent point and would like to see his = question addressed. > - We know there is a security hole even with LSP which already has > seq# and authentications, it does not matter how small the hole is. I think this is also debatable. Changes to the protocol come at a cost - bo= th to the protocol vendors and the users of the protocol. I do not share yo= ur opinion that all potential security issues have to be addressed. A prude= nt evaluation of the risks and the costs needs to be made. Les > thus we probably should not say this TLV is not allowed in the LSP=20 > packet > - Operators can make this decision (to use this TLV or not inside the=20 > LSP packet) > base on whatever they see their network security requirements >=20 > - Naiming >=20 > On Oct 27, 2011, at 5:38 PM, Les Ginsberg (ginsberg) wrote: >=20 > > I started this thread to ask what value add the new TLV has when used > in > > LSPs. So far, the discussion has focused on a corner case wherein: > > > > a)The attacker needs to store old LSPs in the hopes that the > originating > > router will be shutdown sometime in the future - a time which may be=20 > > weeks or months after the attacker begins collecting the old LSPs > > > > b)The router to be attacked must shutdown for a period greater than > LSP > > lifetime > > > > c)The attacker must notice that the router to be attacked has > shutdown > > and wait for LSPs to be aged out from all routers in the network > > > > IF all of the above are met the attacker may then cause disruption > for a > > period of time which is proportional to the number of old LSPs it has > > stored - and the disruption period associated with each LSP version=20 > > would be a modest period. > > > > Now, is this the sole usefulness of the new TLV in LSPs? AFAICT it is > - > > but I am asking the authors to speak to this point in case I have=20 > > overlooked something. > > > > If this is the sole use case for the new TLV in LSPs, then I think a=20 > > legitimate question is whether this is a problem worth solving. The=20 > > "security hole" can only be used on rare occasions and isn't > guaranteed > > to provide any opportunity to cause disruption (the router which is=20 > > shutdown may be taken out of service permanently - or be restarted > with > > a new identity - or not be out of service long enough to allow old > LSPs > > to be aged out) and the duration of the disruption is bounded even on > > those rare occasions when the opportunity presents itself. This isn't > a > > compelling justification. > > > > Les > > > >> -----Original Message----- > >> From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On=20 > >> Behalf Of Naiming Shen (naiming) > >> Sent: Thursday, October 27, 2011 3:13 PM > >> To: Mike Shand > >> Cc: isis-wg@ietf.org > >> Subject: Re: [Isis-wg] Question regardingdraft-chunduri-isis- > extended- > >> sequence-no-tlv-00 > >> > >> > >> Hi Mike, > >> > >> You are correct of course. I was just saying this 30 seconds the > > hacker > >> does not have > >> to follow this 300ms timing, and he/she can set this as a 30 seconds > >> fixed interval to release the > >> next attack packet. Also the network routers have hold down timers > for > >> SPFs and they may > >> not react to changes immediately. Even if they do, we will see the=20 > >> network traffic disrupted for every 30 seconds briefly for 2 days=20 > >> in this example. > >> > >> We can change the parameters also, instead of capturing for 3 > months, > >> he/she can do for years. > >> Or the hacker can cause some link change events to force your router > > to > >> generate LSPs > >> more frequently, etc. And instead of cause major disruption for 2 > > days, > >> the hacker might only need > >> to cause trouble for 10 minutes on the net (that amount of > disruption > >> could be a WSJ frontline story). > >> > >> We sure can do lots of things to minimize the impact, but the point > is > >> that the security > >> hole is certainly there. > >> > >> thanks. > >> - Naiming > >> > >> On Oct 27, 2011, at 2:43 PM, Mike Shand wrote: > >> > >>> Hi Naiming, > >>> > >>> I don't understand the assumption of 30 seconds per round. 300mS > per > >> round would be slow. Yes, by delaying each round by 30 seconds you=20 > >> could spread out the disruption, but the disruption would only last > > for > >> a few 100 mS each time around, and would only affect routers between > >> (for some value of between) you and the target router, since the > > target > >> router would respond with its real LSP as soon as it saw your fake > > one. > >>> > >>> But what you say is correct, in that you can store up a lot of > LSPs. > >> if you have 5000 LSPs you have around 2500 opportunities to exert > some > >> disruption, each of which will last for a few hundred mS. > >>> > >>> Remember that for this to happen the target router has not only to > >> have died and reset its seq number, but it has to have remained dead > >> for at least the maximum lifetime, which in many networks these days > > is > >> set to the maximum of > >>> 18 hours or so. If it comes back to life before then, the sequence > >> number will get reset to the current max value of the LSPs still > > extant > >> in the network, and the attacker will have no real opportunity to > use > >> his stored LSPs. > >>> > >>> Mike > >>> > >>> On 27/10/2011 19:48, Naiming Shen wrote: > >>>> Your example is too modest. as I mentioned in the previous email, > >> here again: > >>>> > >>>> Let's assume the hacker was able to capture all of your LSPs in > the > >> past months, > >>>> and got seq# from #50 to #5000 (in 3 months assume 15 minutes > each) > >> on one of > >>>> your routers. This week the hacker noticed this router had reset > > the > >> LSP seq#. > >>>> The most recent new the router sent out being lsp seq#20. > >>>> > >>>> The hacker releases the cached/old LSP seq#50 which has very > >> different content from > >>>> your current seq#20's lsp: > >>>> > >>>> your router responds to regen seq# 51 (new) hacker then replays=20 > >>>> seq# 52 (cached/old) your router responds to regen seq#53 (new)=20 > >>>> hacker then replays seq# 54 (cached/old) .... > >>>> > >>>> this can go on and on until the hacker runs out its seq#5000. > > Assume > >> each round > >>>> takes 30 seconds, this disruption will last for almost 2 days in > >> your network, > >>>> regardless you have authentication or not. > >>>> > >>>> - Naiming > >>>> > >>>> On Oct 26, 2011, at 10:56 PM, Les Ginsberg (ginsberg) wrote: > >>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Naiming Shen (naiming) > >>>>>> Sent: Wednesday, October 26, 2011 10:41 PM > >>>>>> To: Les Ginsberg (ginsberg) > >>>>>> Cc: uma.chunduri@ericsson.com; wenhu.lu@ericsson.com;=20 > >>>>>> albert.tian@ericsson.com; isis mailing list > >>>>>> Subject: Re: Question regarding draft-chunduri-isis-extended- > >> sequence- > >>>>>> no-tlv-00 > >>>>>> > >>>>>> > >>>>>> On Oct 26, 2011, at 10:27 PM, Les Ginsberg (ginsberg) wrote: > >>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Naiming Shen (naiming) > >>>>>>>> Sent: Wednesday, October 26, 2011 10:21 PM > >>>>>>>> To: Les Ginsberg (ginsberg) > >>>>>>>> Cc: uma.chunduri@ericsson.com; wenhu.lu@ericsson.com;=20 > >>>>>>>> albert.tian@ericsson.com; isis mailing list > >>>>>>>> Subject: Re: Question regarding draft-chunduri-isis-extended- > >>>>>> sequence- > >>>>>>>> no-tlv-00 > >>>>>>>> > >>>>>>>> > >>>>>>>> Les, > >>>>>>>> > >>>>>>>> Even a 'very short disruption' is a disruption I would think. > >>>>>>>> > >>>>>>>> But in your example, if I have a way to capture and replay > your > >>>>>> seq#X, > >>>>>>>> then I may > >>>>>>>> also have a way to capture your seq#X+2, and seq#X+4, etc. > >>>>>>>> If you were going to update the LSP to seq#X+1, which does > > cause > >> a > >>>>>>>> brief disruption, > >>>>>>>> then I would release the seq#X+2. and this can go on and on > and > >>>>>> cause > >>>>>>>> a major disruption. > >>>>>>> In order to cause disruption you have to change the content of > >> the > >>>>>> LSP > >>>>>>> (merely resending an identical LSP does no harm - other than=20 > >>>>>>> unnecessarily consuming some CPU time). Once you do that you > > MUST > >>>>>> have > >>>>>>> the key in order to recalculate the correct message digest - > >>>>>> otherwise > >>>>>>> the bogus LSP fails authentication. So the problemtic scenario > > is > >>>>>>> limited to the transitory (and rare) case I mentioned - it is > > not > >> an > >>>>>>> ongoing disruption. > >>>>>> But since this is your previous life's LSP, let's say last > > months, > >>>>>> there may be > >>>>>> some changes during the months in operation. and you can also > re- > >>>>>> shifting > >>>>>> your content in different LSPs. so there is no guarantee that > the > >> same > >>>>>> LSP > >>>>>> last year will have the same content of this year. > >>>>> So, last week I sent LSP #0 with Seq # 100 and a certain set of > >> TLVs > >>>>> (call this OLD-TLVs). > >>>>> I get shutdown for a week and restarted (cold start) and I send > > LSP > >> #0 > >>>>> with Seq #1 with a new set of TLVs (call this NEW-TLVs). > >>>>> > >>>>> You as the evil attacker now send LSP #0 Seq #100 OLD-TLVs. As it > >> has > >>>>> valid authentication it is accepted by routers who receive it and > >> some > >>>>> disruption occurs. However once I receive it I recognize it as > not > >>>>> matching my local copy and I immediately generate and flood LSP > #0 > >> Seq > >>>>> #101 NEW-TLVS. This corrects the problem. > >>>>> > >>>>> Now you (evil attacker) have only the following options: > >>>>> > >>>>> 1)You can send saved copies of LSP #0 w Seq #<=3D 100 OLD-TLVS. > > These > >>>>> will have valid authentication - but will be discarded by all > >> routers as > >>>>> being older than the latest version (Seq #101) that I have > >> previously > >>>>> sent. > >>>>> > >>>>> 2)You can resend LSP #0 w Seq #101 w content unchanged (NEW- > TLVs). > >> Again > >>>>> this will have valid authentication but as the content is > > unchanged > >> it > >>>>> causes no disruption. > >>>>> > >>>>> 3)You can send LSP #0 w Seq #> 101 OLD-TLVs, but since you don't > >> have > >>>>> the key authentication will fail on these LSPs and they will be=20 > >>>>> discarded. > >>>>> > >>>>> So you get one - and only one - chance to cause disruption - and > >> this > >>>>> lasts only briefly and your opportunity only arises in cases > where > >> a > >>>>> router has cold started after being shutdown long enough for the > >> LSPs > >>>>> sent by the old incarnation to be aged out from the network. > >>>>> > >>>>> Les > >>>>> > >>>>>> - Naiming > >>>>>> > >>>>>>> Les > >>>>>>> > >>>>>>>> thanks. > >>>>>>>> - Naiming > >>>>>>>> > >>>>>>>>> > >>>>>>>>> It is conceivable that if a router had generated an LSP with > >> seq > >>>>> #X > >>>>>>>> and > >>>>>>>>> then shutdown for a time and then restarted sending LSP w > >> seq#1, > >>>>>>> that > >>>>>>>>> the adversary could replay the LSP w seq #X and it would (in > >> the > >>>>>>>> absence > >>>>>>>>> of a key change) look valid. However this would create only a > >> very > >>>>>>>> short > >>>>>>>>> disruption - basically the time it took for the restarted > >> router > >>>>> to > >>>>>>>>> generate and flood seq #X+1 - and thereafter attempts by the > >>>>>>>> adversary > >>>>>>>>> to generate valid looking newer versions would again fail. > >>>> _______________________________________________ > >>>> Isis-wg mailing list > >>>> Isis-wg@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/isis-wg > >>> > >>> _______________________________________________ > >>> Isis-wg mailing list > >>> Isis-wg@ietf.org > >>> https://www.ietf.org/mailman/listinfo/isis-wg > >> > >> _______________________________________________ > >> Isis-wg mailing list > >> Isis-wg@ietf.org > >> https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From uma.chunduri@ericsson.com Thu Mar 29 01:51:07 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E2121F889D; Thu, 29 Mar 2012 01:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgekm88GAM9P; Thu, 29 Mar 2012 01:51:06 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 17B7821F8926; Thu, 29 Mar 2012 01:51:06 -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 q2T8p5iY025993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Mar 2012 03:51:05 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 29 Mar 2012 04:51:04 -0400 From: Uma Chunduri To: Naiming Shen , Manav Bhatia Date: Thu, 29 Mar 2012 04:51:01 -0400 Thread-Topic: [Isis-wg] draft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVtg2vKJfesJS3TJmzQjLc+oPIPR3zstUg Message-ID: References: <1319761109.42505.YahooMailNeo@web27406.mail.ukl.yahoo.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: multipart/alternative; boundary="_000_D1D8138DDF34B34B8BC68A11262D10791B8DA39008EUSAACMS0701e_" MIME-Version: 1.0 Cc: isis , "karp@ietf.org" Subject: Re: [karp] [Isis-wg] draft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:51:08 -0000 --_000_D1D8138DDF34B34B8BC68A11262D10791B8DA39008EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [CC'ed KARP too] Hi Manav, For your question as indicated in KARP WG yesterday, we have added the app= licability statement in the '01' version of the draft (presented in ISIS WG= ). Please let us know if you have any further comments. -- Uma C. ________________________________ From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf = Of Naiming Shen Sent: Friday, October 28, 2011 2:10 PM To: Manav Bhatia Cc: isis Subject: Re: [Isis-wg] draft-chunduri-isis-extended-sequence-no-tlv-00 Hi Manav, I agree with Uma that if operators are concerned enough to put authenticati= on to prevent hackers to inject their own isis packets, also to the point they are worrie= d the hmac-md5 might not be enough, or even be cracked, then they should definitely worry = about replay since the hackers don't even need to forge their own packets in order to ca= use disruption. I did a quick Google search, actually there are many discussions online abo= ut the issues relate to the isis in PE-PC, thus it's probably not as rare as "don't ever = find". Good question on what has been changed for ISIS in recent years. One major = thing, the Data Center, the Cloud. ISIS packet is no longer as 15 years ago only running over a few tier 1 ISP= 's backbones, I'm sure you have been involved in introducing layer2, TRILL, OTV, etc into= ISIS protocol. ISIS is currently running in some of the data centers ALREADY. On the same = rack, the switch which runs ISIS may connect to all kinds of server blades belonging to diff= erent admin domains. If hackers often break into those servers to steal credit card numbers, SSN= , files, or change webpage content to make statements, we probably don't want to insist= they have no way to reach the switches just few inches above their servers, both virt= ually and physically. We have seen how devastating when data center network is hosed. The recent = examples of Amazon's cloud and RIM's network, I'm not saying those are security rela= ted cases, but it's probably not too hard to imagine what can bring some companies down or= generate good WSJ stories these days in today's cyber space. thanks. - Naiming On Oct 27, 2011, at 5:18 PM, Manav Bhatia wrote: Hi, We had considered adding support for replay protection when doing RFC 5310.= The reason it was rejected was because we didnt think such an attack was r= eally possible since (i) the attacker has to be on a direct link and (ii) I= SIS is generally run in the service provider "core" router (you dont ever f= ind it as a PE-CE protocol). So, i would first like to understand if someth= ing has changed between then and now to prompt a need for such a mechanism. OSPF is a different beast since OSPF packets can be launched from a site mu= ltiple hops away as they ride over IP - and adding mechanisms to prevent OS= PF replays becomes significant. I would like to understand the motivation h= ere. Cheers, Manav _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg --_000_D1D8138DDF34B34B8BC68A11262D10791B8DA39008EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[CC'ed KARP too]

Hi Manav,
 
For your question as  indicated in KARP WG= =20 yesterday, we have added the applicability statement in the '01' version of= the=20 draft (presented in ISIS WG).
Please=20 let us know if you have any further comments.

--
Uma C.

 

From: isis-wg-bounces@ietf.org=20 [mailto:isis-wg-bounces@ietf.org] On Behalf Of Naiming=20 Shen
Sent: Friday, October 28, 2011 2:10 PM
To: Manav=20 Bhatia
Cc: isis
Subject: Re: [Isis-wg]=20 draft-chunduri-isis-extended-sequence-no-tlv-00


Hi Manav,

I agree with Uma that if operators are concerned enough to put=20 authentication to prevent
hackers to inject their own isis packets, also to the point they are=20 worried the hmac-md5
might not be enough, or even be cracked, then they should definitely w= orry=20 about replay
since the hackers don't even need to forge their own packets in order = to=20 cause disruption.

I did a quick Google search, actually there are many discussions onlin= e=20 about the issues
relate to the isis in PE-PC, thus it's probably not as rare as "don't = ever=20 find".

Good question on what has been changed for ISIS in recent years. One m= ajor=20 thing,
the Data Center, the Cloud.

ISIS packet is no longer as 15 years ago only running over a few tier = 1=20 ISP's backbones,
I'm sure you have been involved in introducing layer2, TRILL, OTV, etc= into=20 ISIS protocol.
ISIS is currently running in some of the data centers ALREADY. On the = same=20 rack, the switch
which runs ISIS may connect to all kinds of server blades belongi= ng to=20 different admin domains.
If hackers often break into those servers to steal credit card numbers= ,=20 SSN, files, or
change webpage content to make statements, we probably don't want to i= nsist=20 they have
no way to reach the switches just few inches above their servers, both= =20 virtually and
physically.

We have seen how devastating when data center network is hosed. The re= cent=20 examples
of Amazon's cloud and RIM's network, I'm not saying those are security= =20 related cases, but
it's probably not too hard to imagine what can bring some companies do= wn or=20 generate
good WSJ stories these days in today's cyber space.

thanks.
- Naiming

On Oct 27, 2011, at 5:18 PM, Manav Bhatia wrote:
Hi,

We had considered adding support for replay protection when doing RF= C=20 5310. The reason it was rejected was because we didnt think such an attac= k was=20 really possible since (i) the attacker has to be on a direct link and (ii= )=20 ISIS is generally run in the service provider "core" router (you dont eve= r=20 find it as a PE-CE protocol). So, i would first like to understand if=20 something has changed between then and now to prompt a need for such a=20 mechanism.

OSPF is a different beast since OSPF packets can be launched from a = site=20 multiple hops away as they ride over IP - and adding mechanisms to preven= t=20 OSPF replays becomes significant. I would like to understand the motivati= on=20 here.

Cheers,=20 Manav
_______________________________________________Isis-wg=20 mailing list
Isis-wg@ietf.org
https://www.ietf= .org/mailman/listinfo/isis-wg

--_000_D1D8138DDF34B34B8BC68A11262D10791B8DA39008EUSAACMS0701e_-- From uma.chunduri@ericsson.com Thu Mar 29 02:01:10 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89AF21F88B1 for ; Thu, 29 Mar 2012 02:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOng9A9I5WZ4 for ; Thu, 29 Mar 2012 02:01:09 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 77CE421F88A7 for ; Thu, 29 Mar 2012 02:01:09 -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 q2T915pD022927; Thu, 29 Mar 2012 04:01:06 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 29 Mar 2012 05:00:59 -0400 From: Uma Chunduri To: Gregory Lebovitz , Sam Hartman Date: Thu, 29 Mar 2012 05:00:58 -0400 Thread-Topic: [karp] threats-reqs: New requirements document for KMP Thread-Index: Ac0JGi75k/zj6qCJSbOJU4WszZim8gEb4MEg Message-ID: References: <6EFEEA85-1E82-4592-A258-E350F5F8D45D@cisco.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: multipart/alternative; boundary="_000_D1D8138DDF34B34B8BC68A11262D10791B8DA39009EUSAACMS0701e_" MIME-Version: 1.0 Cc: "karp@ietf.org" Subject: Re: [karp] threats-reqs: New requirements document for KMP X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:01:10 -0000 --_000_D1D8138DDF34B34B8BC68A11262D10791B8DA39009EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable GL> NEW: GL> "Work Phase 2", a framework and usage of a KMP, GL> will be addressed in a future document(s)." GL> GL> This would occur in both the introduction and the 1st GL> paragraph of section 4. I guess, this is more clear now and also clarified in WG. I hope you meant future protocol (group of protocols) gap analysis/requirements document. -- Uma C. --_000_D1D8138DDF34B34B8BC68A11262D10791B8DA39009EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
GL> NEW:  
GL> "Work Phase 2", a f=
ramework and usage of a KMP, 
GL> will be addressed in a future document(s)."
GL>
GL> This would occur in both the introduction and the 1=
st
GL> paragraph of sec=
tion 4. 
 
I guess, this is =
more clear now and also clarified in WG. 
I hope you meant fu=
ture protocol (group of protocols) gap 
analysis/requirements=
 document. 
 
--
Uma C.
 
 
 
 
--_000_D1D8138DDF34B34B8BC68A11262D10791B8DA39009EUSAACMS0701e_-- From touch@isi.edu Thu Mar 29 13:43:41 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCD621E801B for ; Thu, 29 Mar 2012 13:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.514 X-Spam-Level: X-Spam-Status: No, score=-103.514 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdxClpOCWl4z for ; Thu, 29 Mar 2012 13:43:39 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id ECB9921E805F for ; Thu, 29 Mar 2012 13:43:06 -0700 (PDT) Received: from [192.168.6.166] ([216.53.135.2]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q2TKgcpl023190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Mar 2012 13:42:41 -0700 (PDT) Message-ID: <4F74C93F.5050501@isi.edu> Date: Thu, 29 Mar 2012 13:42:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: karp@ietf.org Subject: Re: [karp] Comments on draft-ietf-karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 20:43:41 -0000 Hi, all, Since some questions have been raised on the relationship of the TCP-AO KMP to this document, and I'm not in Paris, let me clarify my views below. Joe 1) I don't see the need for this doc at all The doc tries to describe a single view of persistent keying information used in different security protocols, but it's not clear why this is ever necessary. Is this information intended to be used for multiple or varying protocols? If so, why does that even make sense, given the varying protections such protocols afford? 2) if there is such a doc, it's meaningless unless it gives examples of how it can be viably interpreted in terms of existing KMPs; primary among these would be static keys (e.g., as currently widely used for TCP-MD5) and IKEv2 This includes resolving the fact that different KMPs and crypto protocols already store information in a variety of locations, and the relationship between that information and the crypto key tables database needs to be defined. How are they coordinated? Which takes precedence when they differ? 3) this doc has no relationship per se to the Gatekeeper in the KARP TCP-AO KMP approach The Gatekeeper is a mechanism introduced in KARP TCP-AO KMP to enable the use of IKEv2 with TCP-AO without changing either protocol (the only mods are new codepoints and extensions as IKEv2 already supports). It may or may not make sense to think of the ways in which IKEv2, the Gatekeeper, and TCP-AO manage keying material in terms of crypto-tables. If not, that is IMO a deficiency of this new, artificial view of the crypto-keytables document. IMO there is no rationale for crypto-keytables as the single viable approach to KARP, and I continue to see crypto-keytables as irrelevant except in broad principles (e.g., as a user or network manager API). ---- From uma.chunduri@ericsson.com Thu Mar 29 17:02:19 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C868221F8535; Thu, 29 Mar 2012 17:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.823 X-Spam-Level: X-Spam-Status: No, score=-5.823 tagged_above=-999 required=5 tests=[AWL=-0.424, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n85wvrMx7r3O; Thu, 29 Mar 2012 17:02:18 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0C021F8533; Thu, 29 Mar 2012 17:02:18 -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 q2U02D9W024061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Mar 2012 19:02:13 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 29 Mar 2012 20:02:12 -0400 From: Uma Chunduri To: "Les Ginsberg (ginsberg)" , "Naiming Shen (naiming)" Date: Thu, 29 Mar 2012 20:02:10 -0400 Thread-Topic: [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQ Message-ID: References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.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 Cc: Mike Shand , "isis-wg@ietf.org" , "karp@ietf.org" Subject: Re: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 00:02:19 -0000 Hi Les, Plz see my response to your concerns in-line [Uma]=20 --=20 Uma C.=20 -----Original Message----- From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]=20 Sent: Thursday, March 29, 2012 2:25 PM To: Uma Chunduri; Naiming Shen (naiming) Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org Subject: RE: [Isis-wg] Question regardingdraft-chunduri-isis-extended-seque= nce-no-tlv-00 Uma - The response you make below does not address the points raised by Mike and = myself. It is understood that the difference=20 between one version of a given LSP and another may be small or large in ter= ms of the number of TLVs that have changed.=20 This point was not mentioned at all by Mike or myself. Here is a summary of the concerns we raised: 1)LSPs already have a built in sequence number which allows ISs to recogniz= e a valid but stale version of an LSP [Uma]: No, ISs can't recognize stale version, if this is replayed from the = previous session. I guess, we have clearly mentioned this in the document. 2)Normal operation of the Update Process recovers from the presence of a st= ale but valid LSP quickly (in tens to hundreds of milliseconds) by having t= he originator regenerate its LSP with higher sequence #. This is a scenario= which is encountered in normal operation following a restart and is handle= d correctly and promptly today.=20 [Uma]: This need not be *always* TRUE. Of course, the above happens only if= the networks still has the restarted IS's LSP/LSP-fragments still not aged= out. 3)The replay scenario discussed in the thread postulated that an attacker c= ould store many old LSPs and replay them one at a time. For this attack to = be possible all of the following conditions would need to be met: a)Attacker stores "many" LSPs without knowing whether a system will ever re= start and if it does when that restart will occur - which could be months o= r years later b)A system shuts down and does not restart until all of its LSPs have aged = out of the network - which can be up to 18 hours depending on the configure= d value for LSP Maxage c)After a system restarts the attacker recognizes that the system has resta= rted and replays each of the stored LSPs with some discrete time interval b= etween replays Should all of the conditions be met it would still be true that the replay = of any version of a given LSP would only cause=20 [Uma]: The above conditions are not impossible for an attacker (by definiti= on an adversary is absolutely motivated) a short disruption as the base protocol mechanisms mention in #2 above woul= d provide quick recovery. [Uma]: Again "short"?? I would only say it depends.. As I mentioned earlier= , in #2 you are assuming you always have the restarted IS's LSP/LSP-fragmen= ts not aged out.=20 After IS restart or brought back in service, for any potential repla= y *all* nodes in the network have to flap the routes.=20 This can happen multiple times to multiple LSP fragments (depending = on how these are replayed) and every time all nodes=20 in the network are impacted which ever process the replay.=20 All of the above raises the question as to whether extended sequence # is n= eeded in LSPs given the scenarios in which it adds any value at all are sev= erely limited and the value it adds is also limited i.e. the protocol will = recover even in the absence of the extended sequence number and will do so = quickly Could you please respond to the above? [Uma] Hope I clarified above and again the word "quickly" is subjective in = the example I provided. =20 There are then additional discussions to be had regarding the usefulness of= the extended sequence # in SNPs and hellos - but let's leave that to anoth= er thread. [Uma] Sure, the additional discussion on the other messages are equally imp= ortant and we need your feedback/comments. Thanx. Les From ginsberg@cisco.com Thu Mar 29 14:24:54 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6390221E8036; Thu, 29 Mar 2012 14:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.332 X-Spam-Level: X-Spam-Status: No, score=-9.332 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkSI5JxqSquI; Thu, 29 Mar 2012 14:24:52 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B729621E801F; Thu, 29 Mar 2012 14:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=17953; q=dns/txt; s=iport; t=1333056292; x=1334265892; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Ec60ULKQ+xTVRVjKVkQX2BobaTzqYuz5NEORtnQoSqo=; b=Uu9kG1AtqaIayaQdn5LZxFlPu3LQ0wH3F5N0eDpzjogkICFrZKC2uDT8 cUh6oNtBKi6AmlV7WdZiLfrEd2t+wBrcIVgq/tZACJG0qbzSsVSvSQNMI QqIqQ8RpctLf46bOjkoyMLKgEuVh3AUGthcRWsvD2vJz/5Nq99g6iN0v5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMAAMLSdE+rRDoH/2dsb2JhbAA5CadUkVGBB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggRCYdjBAELn0eXOwSKdAOFM2MEiFibT4FogweBNAg X-IronPort-AV: E=Sophos;i="4.75,339,1330905600"; d="scan'208";a="35159511" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 29 Mar 2012 21:24:52 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2TLOqFN020392; Thu, 29 Mar 2012 21:24:52 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 14:24:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 14:24:51 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94A== References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.com> From: "Les Ginsberg (ginsberg)" To: "Uma Chunduri" , "Naiming Shen (naiming)" X-OriginalArrivalTime: 29 Mar 2012 21:24:52.0106 (UTC) FILETIME=[60CF56A0:01CD0DF2] X-Mailman-Approved-At: Fri, 30 Mar 2012 00:21:31 -0700 Cc: Mike Shand , isis-wg@ietf.org, karp@ietf.org Subject: Re: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:24:54 -0000 Uma - The response you make below does not address the points raised by Mike and myself. It is understood that the difference between one version of a given LSP and another may be small or large in terms of the number of TLVs that have changed. This point was not mentioned at all by Mike or myself. Here is a summary of the concerns we raised: 1)LSPs already have a built in sequence number which allows ISs to recognize a valid but stale version of an LSP 2)Normal operation of the Update Process recovers from the presence of a stale but valid LSP quickly (in tens to hundreds of milliseconds) by having the originator regenerate its LSP with higher sequence #. This is a scenario which is encountered in normal operation following a restart and is handled correctly and promptly today.=20 3)The replay scenario discussed in the thread postulated that an attacker could store many old LSPs and replay them one at a time. For this attack to be possible all of the following conditions would need to be met: a)Attacker stores "many" LSPs without knowing whether a system will ever restart and if it does when that restart will occur - which could be months or years later b)A system shuts down and does not restart until all of its LSPs have aged out of the network - which can be up to 18 hours depending on the configured value for LSP Maxage c)After a system restarts the attacker recognizes that the system has restarted and replays each of the stored LSPs with some discrete time interval between replays Should all of the conditions be met it would still be true that the replay of any version of a given LSP would only cause a short disruption as the base protocol mechanisms mention in #2 above would provide quick recovery. All of the above raises the question as to whether extended sequence # is needed in LSPs given the scenarios in which it adds any value at all are severely limited and the value it adds is also limited i.e. the protocol will recover even in the absence of the extended sequence number and will do so quickly Could you please respond to the above? There are then additional discussions to be had regarding the usefulness of the extended sequence # in SNPs and hellos - but let's leave that to another thread. Thanx. Les > -----Original Message----- > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > Sent: Thursday, March 29, 2012 1:51 AM > To: Les Ginsberg (ginsberg); Naiming Shen (naiming) > Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org > Subject: RE: [Isis-wg] Question regardingdraft-chunduri-isis-extended- > sequence-no-tlv-00 >=20 > [CC'ed KARP too] >=20 > In the ISIS wg meeting in Paris, we addressed the concerns raised by Les and > Mike in the mailing list. > As asked by chairs we are summarizing here, the points briefly discussed > specifically on the ESN TLV in LSP. >=20 > - Though, the originator updates the sequence number and floods the same when > replay is received, > the impact of the replayed LSP in the network *purely* depends on the > content of the replayed packet > (this could be fewer TLV22s/222s or ..) and also all the nodes in the > area/domain could be impacted. > - plz note an adversary can potentially do this for any LSP fragment of > a particular node/any node. > - As rightly pointed by Mike, on the 18hrs max age configuration > - if a node/card in the network need to be serviced one can't assume > always this can be done > in this time > - Still ISO default MAXAGE (20mins) is seen in the deployments > - In this sense as Naiming indicated if this optional TLV protection is > needed or not > could be decided by the operator. > -- > Uma C. >=20 >=20 > -----Original Message----- > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf Of > Les Ginsberg (ginsberg) > Sent: Thursday, October 27, 2011 6:26 PM > To: Naiming Shen (naiming) > Cc: Mike Shand; isis-wg@ietf.org > Subject: Re: [Isis-wg] Question regardingdraft-chunduri-isis-extended- > sequence-no-tlv-00 >=20 > Naiming - >=20 > > -----Original Message----- > > From: Naiming Shen (naiming) > > Sent: Thursday, October 27, 2011 6:18 PM > > To: Les Ginsberg (ginsberg) > > Cc: Mike Shand; isis-wg@ietf.org > > Subject: Re: [Isis-wg] Question regardingdraft-chunduri-isis-extended- > > sequence-no-tlv-00 > > > > > > My opinion is this: > > > > - We know we need to have this TLV in non-LSP ISIS packets for obvious > > reasons >=20 > I don't think we have consensus on this yet. I have other concerns regarding > SNPs and IIHs which I have not yet raised as I thought it would be easier to > discuss one PDU at a time. :-) >=20 > I also think Manav has raised an excellent point and would like to see his > question addressed. >=20 > > - We know there is a security hole even with LSP which already has > > seq# and authentications, it does not matter how small the hole is. >=20 > I think this is also debatable. Changes to the protocol come at a cost - both > to the protocol vendors and the users of the protocol. I do not share your > opinion that all potential security issues have to be addressed. A prudent > evaluation of the risks and the costs needs to be made. >=20 > Les >=20 > > thus we probably should not say this TLV is not allowed in the LSP > > packet > > - Operators can make this decision (to use this TLV or not inside the > > LSP packet) > > base on whatever they see their network security requirements > > > > - Naiming > > > > On Oct 27, 2011, at 5:38 PM, Les Ginsberg (ginsberg) wrote: > > > > > I started this thread to ask what value add the new TLV has when > used > > in > > > LSPs. So far, the discussion has focused on a corner case wherein: > > > > > > a)The attacker needs to store old LSPs in the hopes that the > > originating > > > router will be shutdown sometime in the future - a time which may be > > > weeks or months after the attacker begins collecting the old LSPs > > > > > > b)The router to be attacked must shutdown for a period greater than > > LSP > > > lifetime > > > > > > c)The attacker must notice that the router to be attacked has > > shutdown > > > and wait for LSPs to be aged out from all routers in the network > > > > > > IF all of the above are met the attacker may then cause disruption > > for a > > > period of time which is proportional to the number of old LSPs it > has > > > stored - and the disruption period associated with each LSP version > > > would be a modest period. > > > > > > Now, is this the sole usefulness of the new TLV in LSPs? AFAICT it > is > > - > > > but I am asking the authors to speak to this point in case I have > > > overlooked something. > > > > > > If this is the sole use case for the new TLV in LSPs, then I think a > > > legitimate question is whether this is a problem worth solving. The > > > "security hole" can only be used on rare occasions and isn't > > guaranteed > > > to provide any opportunity to cause disruption (the router which is > > > shutdown may be taken out of service permanently - or be restarted > > with > > > a new identity - or not be out of service long enough to allow old > > LSPs > > > to be aged out) and the duration of the disruption is bounded even > on > > > those rare occasions when the opportunity presents itself. This > isn't > > a > > > compelling justification. > > > > > > Les > > > > > >> -----Original Message----- > > >> From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On > > >> Behalf Of Naiming Shen (naiming) > > >> Sent: Thursday, October 27, 2011 3:13 PM > > >> To: Mike Shand > > >> Cc: isis-wg@ietf.org > > >> Subject: Re: [Isis-wg] Question regardingdraft-chunduri-isis- > > extended- > > >> sequence-no-tlv-00 > > >> > > >> > > >> Hi Mike, > > >> > > >> You are correct of course. I was just saying this 30 seconds the > > > hacker > > >> does not have > > >> to follow this 300ms timing, and he/she can set this as a 30 > seconds > > >> fixed interval to release the > > >> next attack packet. Also the network routers have hold down timers > > for > > >> SPFs and they may > > >> not react to changes immediately. Even if they do, we will see the > > >> network traffic disrupted for every 30 seconds briefly for 2 days > > >> in this example. > > >> > > >> We can change the parameters also, instead of capturing for 3 > > months, > > >> he/she can do for years. > > >> Or the hacker can cause some link change events to force your > router > > > to > > >> generate LSPs > > >> more frequently, etc. And instead of cause major disruption for 2 > > > days, > > >> the hacker might only need > > >> to cause trouble for 10 minutes on the net (that amount of > > disruption > > >> could be a WSJ frontline story). > > >> > > >> We sure can do lots of things to minimize the impact, but the point > > is > > >> that the security > > >> hole is certainly there. > > >> > > >> thanks. > > >> - Naiming > > >> > > >> On Oct 27, 2011, at 2:43 PM, Mike Shand wrote: > > >> > > >>> Hi Naiming, > > >>> > > >>> I don't understand the assumption of 30 seconds per round. 300mS > > per > > >> round would be slow. Yes, by delaying each round by 30 seconds you > > >> could spread out the disruption, but the disruption would only last > > > for > > >> a few 100 mS each time around, and would only affect routers > between > > >> (for some value of between) you and the target router, since the > > > target > > >> router would respond with its real LSP as soon as it saw your fake > > > one. > > >>> > > >>> But what you say is correct, in that you can store up a lot of > > LSPs. > > >> if you have 5000 LSPs you have around 2500 opportunities to exert > > some > > >> disruption, each of which will last for a few hundred mS. > > >>> > > >>> Remember that for this to happen the target router has not only to > > >> have died and reset its seq number, but it has to have remained > dead > > >> for at least the maximum lifetime, which in many networks these > days > > > is > > >> set to the maximum of > > >>> 18 hours or so. If it comes back to life before then, the sequence > > >> number will get reset to the current max value of the LSPs still > > > extant > > >> in the network, and the attacker will have no real opportunity to > > use > > >> his stored LSPs. > > >>> > > >>> Mike > > >>> > > >>> On 27/10/2011 19:48, Naiming Shen wrote: > > >>>> Your example is too modest. as I mentioned in the previous email, > > >> here again: > > >>>> > > >>>> Let's assume the hacker was able to capture all of your LSPs in > > the > > >> past months, > > >>>> and got seq# from #50 to #5000 (in 3 months assume 15 minutes > > each) > > >> on one of > > >>>> your routers. This week the hacker noticed this router had reset > > > the > > >> LSP seq#. > > >>>> The most recent new the router sent out being lsp seq#20. > > >>>> > > >>>> The hacker releases the cached/old LSP seq#50 which has very > > >> different content from > > >>>> your current seq#20's lsp: > > >>>> > > >>>> your router responds to regen seq# 51 (new) hacker then replays > > >>>> seq# 52 (cached/old) your router responds to regen seq#53 (new) > > >>>> hacker then replays seq# 54 (cached/old) .... > > >>>> > > >>>> this can go on and on until the hacker runs out its seq#5000. > > > Assume > > >> each round > > >>>> takes 30 seconds, this disruption will last for almost 2 days in > > >> your network, > > >>>> regardless you have authentication or not. > > >>>> > > >>>> - Naiming > > >>>> > > >>>> On Oct 26, 2011, at 10:56 PM, Les Ginsberg (ginsberg) wrote: > > >>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Naiming Shen (naiming) > > >>>>>> Sent: Wednesday, October 26, 2011 10:41 PM > > >>>>>> To: Les Ginsberg (ginsberg) > > >>>>>> Cc: uma.chunduri@ericsson.com; wenhu.lu@ericsson.com; > > >>>>>> albert.tian@ericsson.com; isis mailing list > > >>>>>> Subject: Re: Question regarding draft-chunduri-isis-extended- > > >> sequence- > > >>>>>> no-tlv-00 > > >>>>>> > > >>>>>> > > >>>>>> On Oct 26, 2011, at 10:27 PM, Les Ginsberg (ginsberg) wrote: > > >>>>>> > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Naiming Shen (naiming) > > >>>>>>>> Sent: Wednesday, October 26, 2011 10:21 PM > > >>>>>>>> To: Les Ginsberg (ginsberg) > > >>>>>>>> Cc: uma.chunduri@ericsson.com; wenhu.lu@ericsson.com; > > >>>>>>>> albert.tian@ericsson.com; isis mailing list > > >>>>>>>> Subject: Re: Question regarding draft-chunduri-isis-extended- > > >>>>>> sequence- > > >>>>>>>> no-tlv-00 > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Les, > > >>>>>>>> > > >>>>>>>> Even a 'very short disruption' is a disruption I would think. > > >>>>>>>> > > >>>>>>>> But in your example, if I have a way to capture and replay > > your > > >>>>>> seq#X, > > >>>>>>>> then I may > > >>>>>>>> also have a way to capture your seq#X+2, and seq#X+4, etc. > > >>>>>>>> If you were going to update the LSP to seq#X+1, which does > > > cause > > >> a > > >>>>>>>> brief disruption, > > >>>>>>>> then I would release the seq#X+2. and this can go on and on > > and > > >>>>>> cause > > >>>>>>>> a major disruption. > > >>>>>>> In order to cause disruption you have to change the content of > > >> the > > >>>>>> LSP > > >>>>>>> (merely resending an identical LSP does no harm - other than > > >>>>>>> unnecessarily consuming some CPU time). Once you do that you > > > MUST > > >>>>>> have > > >>>>>>> the key in order to recalculate the correct message digest - > > >>>>>> otherwise > > >>>>>>> the bogus LSP fails authentication. So the problemtic scenario > > > is > > >>>>>>> limited to the transitory (and rare) case I mentioned - it is > > > not > > >> an > > >>>>>>> ongoing disruption. > > >>>>>> But since this is your previous life's LSP, let's say last > > > months, > > >>>>>> there may be > > >>>>>> some changes during the months in operation. and you can also > > re- > > >>>>>> shifting > > >>>>>> your content in different LSPs. so there is no guarantee that > > the > > >> same > > >>>>>> LSP > > >>>>>> last year will have the same content of this year. > > >>>>> So, last week I sent LSP #0 with Seq # 100 and a certain set of > > >> TLVs > > >>>>> (call this OLD-TLVs). > > >>>>> I get shutdown for a week and restarted (cold start) and I send > > > LSP > > >> #0 > > >>>>> with Seq #1 with a new set of TLVs (call this NEW-TLVs). > > >>>>> > > >>>>> You as the evil attacker now send LSP #0 Seq #100 OLD-TLVs. As > it > > >> has > > >>>>> valid authentication it is accepted by routers who receive it > and > > >> some > > >>>>> disruption occurs. However once I receive it I recognize it as > > not > > >>>>> matching my local copy and I immediately generate and flood LSP > > #0 > > >> Seq > > >>>>> #101 NEW-TLVS. This corrects the problem. > > >>>>> > > >>>>> Now you (evil attacker) have only the following options: > > >>>>> > > >>>>> 1)You can send saved copies of LSP #0 w Seq #<=3D 100 = OLD-TLVS. > > > These > > >>>>> will have valid authentication - but will be discarded by all > > >> routers as > > >>>>> being older than the latest version (Seq #101) that I have > > >> previously > > >>>>> sent. > > >>>>> > > >>>>> 2)You can resend LSP #0 w Seq #101 w content unchanged (NEW- > > TLVs). > > >> Again > > >>>>> this will have valid authentication but as the content is > > > unchanged > > >> it > > >>>>> causes no disruption. > > >>>>> > > >>>>> 3)You can send LSP #0 w Seq #> 101 OLD-TLVs, but since you > don't > > >> have > > >>>>> the key authentication will fail on these LSPs and they will be > > >>>>> discarded. > > >>>>> > > >>>>> So you get one - and only one - chance to cause disruption - and > > >> this > > >>>>> lasts only briefly and your opportunity only arises in cases > > where > > >> a > > >>>>> router has cold started after being shutdown long enough for the > > >> LSPs > > >>>>> sent by the old incarnation to be aged out from the network. > > >>>>> > > >>>>> Les > > >>>>> > > >>>>>> - Naiming > > >>>>>> > > >>>>>>> Les > > >>>>>>> > > >>>>>>>> thanks. > > >>>>>>>> - Naiming > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> It is conceivable that if a router had generated an LSP with > > >> seq > > >>>>> #X > > >>>>>>>> and > > >>>>>>>>> then shutdown for a time and then restarted sending LSP w > > >> seq#1, > > >>>>>>> that > > >>>>>>>>> the adversary could replay the LSP w seq #X and it would (in > > >> the > > >>>>>>>> absence > > >>>>>>>>> of a key change) look valid. However this would create only > a > > >> very > > >>>>>>>> short > > >>>>>>>>> disruption - basically the time it took for the restarted > > >> router > > >>>>> to > > >>>>>>>>> generate and flood seq #X+1 - and thereafter attempts by the > > >>>>>>>> adversary > > >>>>>>>>> to generate valid looking newer versions would again fail. > > >>>> _______________________________________________ > > >>>> Isis-wg mailing list > > >>>> Isis-wg@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/isis-wg > > >>> > > >>> _______________________________________________ > > >>> Isis-wg mailing list > > >>> Isis-wg@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/isis-wg > > >> > > >> _______________________________________________ > > >> Isis-wg mailing list > > >> Isis-wg@ietf.org > > >> https://www.ietf.org/mailman/listinfo/isis-wg >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From ginsberg@cisco.com Thu Mar 29 17:59:00 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF1E21E8093; Thu, 29 Mar 2012 17:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.342 X-Spam-Level: X-Spam-Status: No, score=-9.342 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62Eki73hKfNG; Thu, 29 Mar 2012 17:58:59 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id AD6F521E8043; Thu, 29 Mar 2012 17:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=6147; q=dns/txt; s=iport; t=1333069137; x=1334278737; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nOT3H1ktRQdN7owmj88/ZsOcFO96YK5Ej3u+Ecj8Cx4=; b=aFUcIauXz9Z5Y6igyaPt/JfHFjsLhPpvRT67uzn8R0M4dLh7oJpwvojK p91ltYwCFBK/RQG1Aosnrl4OOcyLnqBocQklE/nOuz3txpkPIi3kNyjQm slC34zedYyYbTepT4wtp3SeIh6blqAPWca564TKW7JZ2V+SOwMbIn9lHv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPEEdU+rRDoH/2dsb2JhbABEuRqBB4IJAQEBAwESAR0KPwUHBAIBCBEEAQELBhcBBgFFCQgBAQQBEggah2MEAZwHnyWKd4UzYwSIWJtPgWiDB4E0 X-IronPort-AV: E=Sophos;i="4.75,339,1330905600"; d="scan'208";a="38210921" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 30 Mar 2012 00:58:57 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2U0wv0C018874; Fri, 30 Mar 2012 00:58:57 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 17:58:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 17:58:56 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMA= References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.com> From: "Les Ginsberg (ginsberg)" To: "Uma Chunduri" , "Naiming Shen (naiming)" X-OriginalArrivalTime: 30 Mar 2012 00:58:57.0228 (UTC) FILETIME=[491968C0:01CD0E10] X-Mailman-Approved-At: Fri, 30 Mar 2012 00:21:31 -0700 Cc: Mike Shand , isis-wg@ietf.org, karp@ietf.org Subject: Re: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 00:59:00 -0000 Uma - > -----Original Message----- > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > Sent: Thursday, March 29, 2012 5:02 PM > To: Les Ginsberg (ginsberg); Naiming Shen (naiming) > Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org > Subject: RE: [Isis-wg] Question regardingdraft-chunduri-isis-extended- > sequence-no-tlv-00 >=20 > Hi Les, >=20 > Plz see my response to your concerns in-line [Uma] >=20 > -- > Uma C. >=20 >=20 > -----Original Message----- > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Thursday, March 29, 2012 2:25 PM > To: Uma Chunduri; Naiming Shen (naiming) > Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org > Subject: RE: [Isis-wg] Question regardingdraft-chunduri-isis-extended- > sequence-no-tlv-00 >=20 > Uma - >=20 > The response you make below does not address the points raised by Mike and > myself. It is understood that the difference > between one version of a given LSP and another may be small or large in terms > of the number of TLVs that have changed. > This point was not mentioned at all by Mike or myself. > Here is a summary of the concerns we raised: > 1)LSPs already have a built in sequence number which allows ISs to recognize > a valid but stale version of an LSP >=20 > [Uma]: No, ISs can't recognize stale version, if this is replayed from the > previous session. I guess, we have clearly mentioned this in the document. >=20 This is not correct. What happens is that the LSP with higher sequence number will get propagated until it reaches the originator. The originator will recognize that this LSP is "owned" by itself but looks "newer" (based on sequence #) than what is in its local database. It will immediately generate a new version of the LSP with higher sequence # and flood that - which will replace any versions of the replayed LSP which exist in the network. Depending on where in the network the attacker injects the replayed LSP will influence the response time of the originating node - but the replayed LSP will be replaced in a timely fashion without any extensions to the protocol. Please consult ISO 10589 Section 7.3.15.1 (c) and (d) as well as Sections 7.3.16.1 and 7.3.16.4. > 2)Normal operation of the Update Process recovers from the presence of a > stale but valid LSP quickly (in tens to hundreds of milliseconds) by having > the originator regenerate its LSP with higher sequence #. This is a scenario > which is encountered in normal operation following a restart and is handled > correctly and promptly today. >=20 > [Uma]: This need not be *always* TRUE. Of course, the above happens only if > the networks still has the restarted IS's LSP/LSP-fragments still not aged > out. Agreed. My point is only that the protocol handles this situation today and it can be easily demonstrated. >=20 > 3)The replay scenario discussed in the thread postulated that an attacker > could store many old LSPs and replay them one at a time. For this attack to > be possible all of the following conditions would need to be met: > a)Attacker stores "many" LSPs without knowing whether a system will ever > restart and if it does when that restart will occur - which could be months > or years later > b)A system shuts down and does not restart until all of its LSPs have aged > out of the network - which can be up to 18 hours depending on the configured > value for LSP Maxage > c)After a system restarts the attacker recognizes that the system has > restarted and replays each of the stored LSPs with some discrete time > interval between replays > Should all of the conditions be met it would still be true that the replay of > any version of a given LSP would only cause >=20 > [Uma]: The above conditions are not impossible for an attacker (by definition > an adversary is absolutely motivated) Agreed. But my point is to highlight that an attack of this sort is unlikely to occur and if it does the damage done will be short-lived and not persistent. >=20 > a short disruption as the base protocol mechanisms mention in #2 above would > provide quick recovery. >=20 > [Uma]: Again "short"?? I would only say it depends.. As I mentioned earlier, > in #2 you are assuming you always have the restarted IS's LSP/LSP-fragments > not aged out. No - I am not making that assumption. I am saying that in order for the attack to have any impact the restarted LSPs must have aged out. I think we agree on that. > After IS restart or brought back in service, for any potential replay > *all* nodes in the network have to flap the routes. > This can happen multiple times to multiple LSP fragments (depending on > how these are replayed) and every time all nodes > in the network are impacted which ever process the replay. >=20 > All of the above raises the question as to whether extended sequence # is > needed in LSPs given the scenarios in which it adds any value at all are > severely limited and the value it adds is also limited i.e. the protocol will > recover even in the absence of the extended sequence number and will do so > quickly > Could you please respond to the above? >=20 > [Uma] Hope I clarified above and again the word "quickly" is subjective in > the example I provided. The discussion I want to have is an evaluation of the "return on investment(ROI)" of this extension. Every protocol extension comes with costs. These include the costs of developing the extension, supporting the extension, deploying the extension, and the overhead of processing the extension in each PDU. The enthusiasm for any proposal is proportional to the ROI. Right now, I am seeing a very low ROI in this case. Les >=20 > There are then additional discussions to be had regarding the usefulness of > the extended sequence # in SNPs and hellos - but let's leave that to another > thread. >=20 > [Uma] Sure, the additional discussion on the other messages are equally > important and we need your feedback/comments. >=20 >=20 > Thanx. >=20 > Les From kivinen@iki.fi Fri Mar 30 01:09:44 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1E521F877D for ; Fri, 30 Mar 2012 01:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kombUHn+BB44 for ; Fri, 30 Mar 2012 01:09:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB18821F85D7 for ; Fri, 30 Mar 2012 01:09:41 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2U89ZSl023358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2012 11:09:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2U89Zgt027578; Fri, 30 Mar 2012 11:09:35 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20341.27199.128277.705512@fireball.kivinen.iki.fi> Date: Fri, 30 Mar 2012 11:09:35 +0300 From: Tero Kivinen To: Joe Touch In-Reply-To: <4F74C93F.5050501@isi.edu> References: <4F74C93F.5050501@isi.edu> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 46 min X-Total-Time: 48 min Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Comments on draft-ietf-karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:09:44 -0000 Joe Touch writes: > 1) I don't see the need for this doc at all I disagree. All of the IKEv2 KARP documents are missing one fundamental module, and I do think karp-crypt-tables do cover one piece of architecture which is needed. In following example I will be using (simplified) IPsec architecture terms, as there we have all this defined. In the IPsec architecture (RFC4301) we have 3 main database to store information (ignoring the caching and decorrelation). - SPD - Security Policy Database - SAD - Security Association Database - PAD - Peer Authorization Database The PAD is the database needed by the IKEv2. It contains the IKEv2 related information like what identities to use, what kind of authorization data to use (shared keys, private/public key pairs etc). Currently none of the documents really describe where this database is. It seems some documents assume that it is inside the IKEv2 module, but in practice if we want to reuse code from IPsec IKEv2 implementations this is not true. Quite often the PAD is part of the policymanagement module if the IPsec, and is linked together with actual configuration and SPD and so on. PAD is not really some kind of basic configuration that can fully be given to the IKEv2 library when you start. You do want to give pointers to it when you initiate new negotiation. I.e. when you trigger new security association you most likely already know the SPD and PAD entries associated to it, so you give them to IKEv2, but when you are responding to the security association being created from the other end you usually do lookups to the database when you get more information, i.e initially you lookup what IKE SA algorithms to use based on the IP-address, then when you know the identity of the other end you decide what identity you are going to being using and what kind of authorization credentials you use etc. Because of this tight coupling with the configuration this database is not normally part of IKEv2 library, but reside outside of it. The SPD describes the policy we are going to be using for the traffic, and the SAD describes the actual keying material and instantiated policy based on the SPD. All of those database are described in the RFC4301, which means that as we are not using IPsec architecture we need to describe something similar in our KARP use. Crypto key tables draft describes what I have understood is replacemend of the SAD. I.e. it is the database the KMP (in this case IKEv2) fills in and which is used by the actual transport protocol (TCP-AO instead of AH/ESP). What we are missing in the KARP is the SPD and PAD. SPD can be quite simple, but for PAD we need to support about the same what is described in the section 4.4.3 of the RFC4301. This is about the minimal information needed for IKEv2. This PAD information quite often do come from different sources. I would expect that each routing protocol to configure their own peers, and peers authentication credentials, so that mean the PAD is not coming from just single source, but we need to merge data from the multiple sources to one consistent database used by the IKEv2. How this is done is also missing in the architecture. I.e. how do the routing protocols push their configuration to the PAD. In (at least in some) IPsec implementations the databases are taken care of the policy manager module, which takes events from the below (trigger, rekey, expire), does policy lookup (finds associated SPD and PAD entries), kicks the IKEv2 process forward, waits for it to finish, gets the keys from the IKEv2, and pushes them down to SAD and to the actual traffic encryption module. The same module also gets events from the IKEv2, i.e when new connection comes to the IKEv2 server, this policy manager module will then decide whether it is allowed, which kind of configuration is used by the IKEv2 when it is replying to the packets and when the incoming connection is done, it will again push the keys from the IKEv2 down to SAD. There is still one more event source, naming the configuration changes. I.e. when the configuration is changed (for example a peer is removed from the PAD), new configuration is pushed to this module, and it will then verify that all currently active SAs are still allowed by the new policy and will tear down those which are not allowed anymore. When I was reading the draft-chunduri-karp-using-ikev2-with-tcp-ao I assumed this gatekeeper module is almost the same than what we have in the IPsec in the policy manager module. What bit suprised me was that when I was talking about the draft, I found out that PAD was not supposed to be part of gatekeeper, and I think that is mistake. So I think the proper KARP architecture should be something like this: +----------+ +----------+ | Routing | | Routing | | protocol | | protocol | +----------+ +----------+ | / | ______/ | / +-------+ +--------------+ +--------+ | PAD |-----| Gatekeeper |-----| IKEv2 | +-------+ +--------------+ +--------+ / \ \ +---------+ / \ \_____________ | Policy |-----/ \ \ +---------+ +----------+ +---------+ | Crypto |-------| TCP-AO | | table | +---------+ +----------+ Routing protocols push configuration to gatekeeper, who stores it to PAD and to policy database. IKEv2 talk to the Gatekeeper and fetches that configuration data through it and creates keys, which Gatekeeper then pushes to the crypto table. TCP-AO would then fetch the keys from crypto table and use them. It could also be that TCP-AO talks directly to the Gatekeeper and asks keys from there, and then gatekeeper would be fetching them from the crypto table (SAD). I see crypto table more or less like conceptional database telling what kind of format the SAD needs to have. I do not really expect it to be real text-file on any real systems, it might be actual database on some environments, but quite often it can be just memory database inside the gatekeeper. The reason for crypto table is that in some environments we might have both gatekeeper and some other policy manager module pushing keys there (i.e. if someone later defines a way to use some other KMP which have very different view to things than IKEv2/Gatekeeper). Another reason might be that there might be some other users reading the crypto table than TCP-AO, i.e. someone might want to use some other security mechanisms to protect routing data. -- kivinen@iki.fi From uma.chunduri@ericsson.com Fri Mar 30 03:08:48 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49B421F8698 for ; Fri, 30 Mar 2012 03:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuQxiqCGKAPK for ; Fri, 30 Mar 2012 03:08:47 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C0C7F21F8690 for ; Fri, 30 Mar 2012 03:08:47 -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 q2UA8h4V002548; Fri, 30 Mar 2012 05:08:44 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 30 Mar 2012 06:08:37 -0400 From: Uma Chunduri To: Tero Kivinen , Joe Touch Date: Fri, 30 Mar 2012 06:08:34 -0400 Thread-Topic: [karp] Comments on draft-ietf-karp-crypto-tables Thread-Index: Ac0OTHuDHE5S6+HJSm+K0XOEGpznGwADodCQ Message-ID: References: <4F74C93F.5050501@isi.edu> <20341.27199.128277.705512@fireball.kivinen.iki.fi> In-Reply-To: <20341.27199.128277.705512@fireball.kivinen.iki.fi> 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: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Comments on draft-ietf-karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:08:48 -0000 Hi Tero, I understood the PAD requirement for IKEv2, yes, this is not captured in th= e current version. As we discussed, this is bit orthogonal to the crypto ke= y tables we are talking about here. I will come back on this but, I want to quickly submit "Routing protocols push configuration to gatekeeper, who stores it to PAD a= nd to policy database. IKEv2 talk to the Gatekeeper and fetches that config= uration data through it and creates keys, which Gatekeeper then pushes to t= he crypto table. TCP-AO would then fetch the keys from crypto table and use= them. It could also be that TCP-AO talks directly to the Gatekeeper and as= ks keys from there, and then gatekeeper would be fetching them from the cry= pto table (SAD). " TCP-AO doesn't fetch the keys from crypto tables. Gatekeeper populates the = same to AO, in the form required by AO (MKTs). So in that sense, crypto tab= les are not quite SADs. In IPSec you consult SAD to protect the traffic but= TCP-AO don't consult an external entity like crypto-key-tables (it lkup ra= ther MKTs). So, I didn't quite understand Section 3 of draft-ietf-karp-cryp= to-tables where it describes key selection to protect the eventual data (th= is is inside AO not outside). --=20 Uma C.=20 -----Original Message----- From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Ter= o Kivinen Sent: Friday, March 30, 2012 1:10 AM To: Joe Touch Cc: Sam Hartman; karp@ietf.org Subject: Re: [karp] Comments on draft-ietf-karp-crypto-tables Joe Touch writes: > 1) I don't see the need for this doc at all I disagree. All of the IKEv2 KARP documents are missing one fundamental mod= ule, and I do think karp-crypt-tables do cover one piece of architecture wh= ich is needed. In following example I will be using (simplified) IPsec architecture terms,= as there we have all this defined. In the IPsec architecture (RFC4301) we have 3 main database to store inform= ation (ignoring the caching and decorrelation). - SPD - Security Policy Database - SAD - Security Association Database - PAD - Peer Authorization Database The PAD is the database needed by the IKEv2. It contains the IKEv2 related = information like what identities to use, what kind of authorization data to= use (shared keys, private/public key pairs etc). Currently none of the documents really describe where this database is. It = seems some documents assume that it is inside the IKEv2 module, but in prac= tice if we want to reuse code from IPsec IKEv2 implementations this is not = true. Quite often the PAD is part of the policymanagement module if the IPs= ec, and is linked together with actual configuration and SPD and so on. PAD is not really some kind of basic configuration that can fully be given = to the IKEv2 library when you start. You do want to give pointers to it whe= n you initiate new negotiation. I.e. when you trigger new security associat= ion you most likely already know the SPD and PAD entries associated to it, = so you give them to IKEv2, but when you are responding to the security asso= ciation being created from the other end you usually do lookups to the data= base when you get more information, i.e initially you lookup what IKE SA al= gorithms to use based on the IP-address, then when you know the identity of= the other end you decide what identity you are going to being using and wh= at kind of authorization credentials you use etc. Because of this tight cou= pling with the configuration this database is not normally part of IKEv2 library, but reside outside of it. The SPD describes the policy we are going to be using for the traffic, and = the SAD describes the actual keying material and instantiated policy based = on the SPD. All of those database are described in the RFC4301, which means that as we = are not using IPsec architecture we need to describe something similar in o= ur KARP use. Crypto key tables draft describes what I have understood is replacemend of = the SAD. I.e. it is the database the KMP (in this case IKEv2) fills in and which is used by the actual transport protocol (TCP-AO = instead of AH/ESP). What we are missing in the KARP is the SPD and PAD. SPD can be quite simple= , but for PAD we need to support about the same what is described in the se= ction 4.4.3 of the RFC4301. This is about the minimal information needed fo= r IKEv2. This PAD information quite often do come from different sources. I would ex= pect that each routing protocol to configure their own peers, and peers aut= hentication credentials, so that mean the PAD is not coming from just singl= e source, but we need to merge data from the multiple sources to one consis= tent database used by the IKEv2. How this is done is also missing in the architecture. I.e. how do the routi= ng protocols push their configuration to the PAD. In (at least in some) IPsec implementations the databases are taken care of= the policy manager module, which takes events from the below (trigger, rek= ey, expire), does policy lookup (finds associated SPD and PAD entries), kic= ks the IKEv2 process forward, waits for it to finish, gets the keys from th= e IKEv2, and pushes them down to SAD and to the actual traffic encryption m= odule. The same module also gets events from the IKEv2, i.e when new connec= tion comes to the IKEv2 server, this policy manager module will then decide= whether it is allowed, which kind of configuration is used by the IKEv2 wh= en it is replying to the packets and when the incoming connection is done, = it will again push the keys from the IKEv2 down to SAD. There is still one = more event source, naming the configuration changes. I.e. when the configur= ation is changed (for example a peer is removed from the PAD), new configur= ation is pushed to this module, and it will then verify that all currently = active SAs are still allowed by the new policy and will tear down those whi= ch are not allowed anymore. When I was reading the draft-chunduri-karp-using-ikev2-with-tcp-ao I assume= d this gatekeeper module is almost the same than what we have in the IPsec = in the policy manager module. What bit suprised me was that when I was talk= ing about the draft, I found out that PAD was not supposed to be part of ga= tekeeper, and I think that is mistake. So I think the proper KARP architecture should be something like this: +----------+ +----------+ | Routing | | Routing | | protocol | | protocol | +----------+ +----------+ | / | ______/ | / +-------+ +--------------+ +--------+ | PAD |-----| Gatekeeper |-----| IKEv2 |=20 +-------+ +--------------+ +--------+ / \ \ +---------+ / \ \_____________ | Policy |-----/ \ \ +---------+ +----------+ +---------+ | Crypto |-------| TCP-AO | | table | +---------+ +----------+ Routing protocols push configuration to gatekeeper, who stores it to PAD an= d to policy database. IKEv2 talk to the Gatekeeper and fetches that configu= ration data through it and creates keys, which Gatekeeper then pushes to th= e crypto table. TCP-AO would then fetch the keys from crypto table and use = them. It could also be that TCP-AO talks directly to the Gatekeeper and ask= s keys from there, and then gatekeeper would be fetching them from the cryp= to table (SAD).=20 I see crypto table more or less like conceptional database telling what kin= d of format the SAD needs to have. I do not really expect it to be real tex= t-file on any real systems, it might be actual database on some environment= s, but quite often it can be just memory database inside the gatekeeper. Th= e reason for crypto table is that in some environments we might have both g= atekeeper and some other policy manager module pushing keys there (i.e. if = someone later defines a way to use some other KMP which have very different= view to things than IKEv2/Gatekeeper). Another reason might be that there = might be some other users reading the crypto table than TCP-AO, i.e. someon= e might want to use some other security mechanisms to protect routing data.= =20 -- kivinen@iki.fi _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp From uma.chunduri@ericsson.com Fri Mar 30 03:12:46 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889D521F868C; Fri, 30 Mar 2012 03:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.092 X-Spam-Level: X-Spam-Status: No, score=-6.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJGbhSEdnv-U; Fri, 30 Mar 2012 03:12:44 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A036321F855D; Fri, 30 Mar 2012 03:12:38 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2UACZOl007435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Mar 2012 05:12:35 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 30 Mar 2012 06:12:35 -0400 From: Uma Chunduri To: "Les Ginsberg (ginsberg)" , "Naiming Shen (naiming)" Date: Fri, 30 Mar 2012 06:12:32 -0400 Thread-Topic: [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IA== Message-ID: References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.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 Cc: Mike Shand , "isis-wg@ietf.org" , "karp@ietf.org" Subject: Re: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:12:46 -0000 Hi Les, My replies in-line [Uma] --=20 Uma C.=20 >=20 > Uma - >=20 > The response you make below does not address the points raised by Mike and > myself. It is understood that the difference between one version of a=20 > given LSP and another may be small or large in terms > of the number of TLVs that have changed. > This point was not mentioned at all by Mike or myself. > Here is a summary of the concerns we raised: > 1)LSPs already have a built in sequence number which allows ISs to recognize > a valid but stale version of an LSP >=20 > [Uma]: No, ISs can't recognize stale version, if this is replayed from the > previous session. I guess, we have clearly mentioned this in the document. >=20 This is not correct. What happens is that the LSP with higher sequence number will get propagate= d until it reaches the originator. [Uma]: ... and all the node who processed and acted on this replay are impa= cted. You can't precisely quantify,=20 how long and what impact. The originator will recognize that this LSP is "owned" by itself but looks = "newer" (based on sequence #)=20 than what is in its local database. It will immediately generate a new vers= ion of the LSP with higher=20 sequence # and flood that - which will replace any versions of the replayed= LSP which exist in the network. [Uma]: Now you are talking about the recovery mechanism which is kicked in = by the originator in this situation. Essentially you originally stated - "LSPs already have a built in sequence = number which allows ISs to recognize a valid but stale version of an LSP". When I disagreed on this yo= u are talking about in built recovery mechanism. I would only guess this is the gap, causing you to believe the new TLV whic= h allow you to recognize the replay and drop=20 has low ROI. Depending on where in the network the attacker injects the replayed LSP wil= l influence the response time of the originating node - but the=20 replayed LSP will be replaced in a timely fashion without any extensions to= the protocol. [Uma] Precisely. "Depending on where in the network" replayed LSP will infl= uence the response and in the mean time as I=20 said our FC timers kick-in all the nodes act on this replay (Eg: yeah, my b= acklink check failed and removing all the prefixes=20 corresponding to the same). It's good this situation is recoverable eventua= lly, but the point is you are=20 already impacted. Not only you and *all_nodes* in the network are impacted = ( I mentioned this earlier and I am repeating). Please consult ISO 10589 Section 7.3.15.1 (c) and (d) as well as Sections 7= .3.16.1 and 7.3.16.4. > 2)Normal operation of the Update Process recovers from the presence of a > stale but valid LSP quickly (in tens to hundreds of milliseconds) by having > the originator regenerate its LSP with higher sequence #. This is a scenario > which is encountered in normal operation following a restart and is handled > correctly and promptly today. >=20 > [Uma]: This need not be *always* TRUE. Of course, the above happens only if > the networks still has the restarted IS's LSP/LSP-fragments still not aged > out. Agreed. My point is only that the protocol handles this situation today and it can = be easily demonstrated. >=20 > 3)The replay scenario discussed in the thread postulated that an attacker > could store many old LSPs and replay them one at a time. For this attack to > be possible all of the following conditions would need to be met: > a) Attacker stores "many" LSPs without knowing whether a system will ever > restart and if it does when that restart will occur - which could be months > or years later > b)A system shuts down and does not restart until all of its LSPs have aged > out of the network - which can be up to 18 hours depending on the configured > value for LSP Maxage > c)After a system restarts the attacker recognizes that the system has=20 > restarted and replays each of the stored LSPs with some discrete time=20 > interval between replays Should all of the conditions be met it would=20 > still be true that the replay of > any version of a given LSP would only cause >=20 > [Uma]: The above conditions are not impossible for an attacker (by definition > an adversary is absolutely motivated) Agreed. But my point is to highlight that an attack of this sort is unlikely to occ= ur and if it does the damage done will be short-lived and not persistent. >=20 > a short disruption as the base protocol mechanisms mention in #2 above would > provide quick recovery. >=20 > [Uma]: Again "short"?? I would only say it depends.. As I mentioned earlier, > in #2 you are assuming you always have the restarted IS's LSP/LSP-fragments > not aged out. No - I am not making that assumption. I am saying that in order for the att= ack to have any impact the restarted LSPs must have aged out. I think we ag= ree on that. > After IS restart or brought back in service, for any potential replay > *all* nodes in the network have to flap the routes. > This can happen multiple times to multiple LSP fragments (depending on > how these are replayed) and every time all nodes > in the network are impacted which ever process the replay. >=20 > All of the above raises the question as to whether extended sequence # is > needed in LSPs given the scenarios in which it adds any value at all are > severely limited and the value it adds is also limited i.e. the protocol will > recover even in the absence of the extended sequence number and will do so > quickly > Could you please respond to the above? >=20 > [Uma] Hope I clarified above and again the word "quickly" is subjective in > the example I provided. The discussion I want to have is an evaluation of the "return on investment= (ROI)" of this extension. Every protocol extension comes with costs. These = include the costs of developing the extension, supporting the extension, de= ploying the extension, and the overhead of processing the extension in each= PDU. The enthusiasm for any proposal is proportional to the ROI. Right now= , I am seeing a very low ROI in this case. [Uma]: I would only say, just because we have an in-built recovery, you ca= n't assume a mechanism which mitigates this threat in first place has low R= OI. And coming to the solution, this optional TLV introduce neither comple= xity nor introduce significant overhead in processing. So I didn't quite un= derstand your claim of "low" ROI. Les >=20 > There are then additional discussions to be had regarding the usefulness of > the extended sequence # in SNPs and hellos - but let's leave that to another > thread. >=20 > [Uma] Sure, the additional discussion on the other messages are equally > important and we need your feedback/comments. >=20 >=20 > Thanx. >=20 > Les From touch@isi.edu Fri Mar 30 05:58:58 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C061421F86D9 for ; Fri, 30 Mar 2012 05:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.453 X-Spam-Level: X-Spam-Status: No, score=-103.453 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsLrXzip9O6e for ; Fri, 30 Mar 2012 05:58:58 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0B021F8673 for ; Fri, 30 Mar 2012 05:58:58 -0700 (PDT) Received: from [192.168.6.166] ([216.53.135.2]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q2UCwS2B018153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Mar 2012 05:58:31 -0700 (PDT) Message-ID: <4F75ADF6.1020208@isi.edu> Date: Fri, 30 Mar 2012 05:58:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Tero Kivinen References: <4F74C93F.5050501@isi.edu> <20341.27199.128277.705512@fireball.kivinen.iki.fi> In-Reply-To: <20341.27199.128277.705512@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Comments on draft-ietf-karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 12:58:58 -0000 Hi, Tero, See below. Perhaps we can resolve this by explaining the Gatekeeper as the coordinator of the interpretation of keying info between a variety of protocols, not just TCP-AO and IKEv2 -- which is fine with me. However, we do need to make sure we explain this in a way that allows protocols like TCP-AO to be used without modification, since that shouldn't be necessary. In specific, TCP-AO gets keys inserted from the outside (user or KMP), and consults its own internal tables only. That must not change in this approach IMO. Joe On 3/30/2012 1:09 AM, Tero Kivinen wrote: > Joe Touch writes: >> 1) I don't see the need for this doc at all > > I disagree. All of the IKEv2 KARP documents are missing one > fundamental module, and I do think karp-crypt-tables do cover one > piece of architecture which is needed. Cutting down to IMO the key parts of your note: ... > In the IPsec architecture (RFC4301) we have 3 main database to store > information (ignoring the caching and decorrelation). > > - SPD - Security Policy Database > - SAD - Security Association Database > - PAD - Peer Authorization Database ... > Currently none of the documents really describe where this database > is.... ... > PAD is not really some kind of basic configuration that can fully be > given to the IKEv2 library when you start.... Because of this tight > coupling with the configuration this database is not normally part of > IKEv2 library, but reside outside of it. ... > All of those database are described in the RFC4301, which means that > as we are not using IPsec architecture we need to describe something > similar in our KARP use. IMO, we need to allow KARP solutions to describe how their keys are managed. I don't see the need for KARP to define this outside of a solution. > Crypto key tables draft describes what I have understood is > replacemend of the SAD. I.e. it is the database the KMP (in this case > IKEv2) fills in and which is used by the actual transport protocol > (TCP-AO instead of AH/ESP). > > What we are missing in the KARP is the SPD and PAD. ... The location of the SAD, SPD, and PAD are specific to a particular approach, and need to be explained in a given solution. > This PAD information quite often do come from different sources.... But it can also be in different locations based on the particular solution being deployed. > I > would expect that each routing protocol to configure their own peers, > and peers authentication credentials, so that mean the PAD is not > coming from just single source, but we need to merge data from the > multiple sources to one consistent database used by the IKEv2. > > How this is done is also missing in the architecture. I.e. how do the > routing protocols push their configuration to the PAD. That's an interface implementation issue, not a protocol issue. ... > When I was reading the draft-chunduri-karp-using-ikev2-with-tcp-ao I > assumed this gatekeeper module is almost the same than what we have in > the IPsec in the policy manager module. What bit suprised me was that > when I was talking about the draft, I found out that PAD was not > supposed to be part of gatekeeper, and I think that is mistake. > > So I think the proper KARP architecture should be something like this: > > +----------+ +----------+ > | Routing | | Routing | > | protocol | | protocol | > +----------+ +----------+ > | / > | ______/ > | / > +-------+ +--------------+ +--------+ > | PAD |-----| Gatekeeper |-----| IKEv2 | > +-------+ +--------------+ +--------+ > / \ \ > +---------+ / \ \_____________ > | Policy |-----/ \ \ > +---------+ +----------+ +---------+ > | Crypto |-------| TCP-AO | > | table | +---------+ > +----------+ The Gatekeeper in KARP TCP-AO KMP is solely an interface between TCP-AO and IKEv2. TCP-AO has no interface to a "crypto-table" module. Its information is specific to TCP protection, and doesn't make sense to integrate (nor is it necessary). If you can draw this diagram without a link from the crypto-table to TCP-AO, then that might work. > Routing protocols push configuration to gatekeeper, who stores it to > PAD and to policy database. IKEv2 talk to the Gatekeeper and fetches > that configuration data through it and creates keys, which Gatekeeper > then pushes to the crypto table. TCP-AO would then fetch the keys from > crypto table and use them. TCP-AO doesn't "fetch" anything. MKTs are installed into TCP-AO either directly by the user (manual keying) or by a KMP. That's why I would say that (according to your diagram), the Gatekeeper fetches keying information from the crypto tables and inserts them into TCP-AO at best. Does that work for you? > It could also be that TCP-AO talks directly > to the Gatekeeper and asks keys from there, and then gatekeeper would > be fetching them from the crypto table (SAD). TCP-AO doesn't ask for keys. It has them added from the outside. There's no trigger in TCP-AO to ask for a key, nor should there be according to its architecture. > I see crypto table more or less like conceptional database telling > what kind of format the SAD needs to have That's fine, if the above interpretation works IMO... . I do not really expect it > to be real text-file on any real systems, it might be actual database > on some environments, but quite often it can be just memory database > inside the gatekeeper. The reason for crypto table is that in some > environments we might have both gatekeeper and some other policy > manager module pushing keys there (i.e. if someone later defines a way > to use some other KMP which have very different view to things than > IKEv2/Gatekeeper). Another reason might be that there might be some > other users reading the crypto table than TCP-AO, i.e. someone might > want to use some other security mechanisms to protect routing data. Again, if you say "there might be some other users reading the crypto table than the Gatekeeper", that's consistent with TCP-AO's design. TCP-AO doesn't read external tables; it defines its own internal ones. ---- From ginsberg@cisco.com Fri Mar 30 11:04:25 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5874B21F85F3; Fri, 30 Mar 2012 11:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-HsUXQ7eWi9; Fri, 30 Mar 2012 11:04:24 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1B81421F85EC; Fri, 30 Mar 2012 11:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=8049; q=dns/txt; s=iport; t=1333130664; x=1334340264; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rRK6RL3ikUbZwd4u0V9AM42RxgaCkAgTfgZEFnHxidM=; b=MR7e0Zkbor4+qRu2/ZkOt4yjI7Ki1jxYRgjXlxGRsL43sMHmkzrjOmU3 01VaFOu/ssAy3S0MsdCAPX6iD7xvbFvnpjNYZJswPidENT+gnHGGrTUp3 e90oxjZGJ+6lqbl0cj05dDpCjwyIOrQoCf1f7u41VoTtOgEYzsK490Z7K 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACD1dU+rRDoI/2dsb2JhbABCuH6BB4IJAQEBBBIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAgQBEggTB4dmAZ99lzKKeoUvYwSIWJtPgWiDB4E0 X-IronPort-AV: E=Sophos;i="4.75,345,1330905600"; d="scan'208";a="35831303" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 30 Mar 2012 18:04:23 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2UI4Meo008192; Fri, 30 Mar 2012 18:04:23 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 11:04:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2012 11:04:18 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IAASsDLA References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.com> From: "Les Ginsberg (ginsberg)" To: "Uma Chunduri" , "Naiming Shen (naiming)" X-OriginalArrivalTime: 30 Mar 2012 18:04:19.0771 (UTC) FILETIME=[876478B0:01CD0E9F] X-Mailman-Approved-At: Fri, 30 Mar 2012 13:28:28 -0700 Cc: Mike Shand , isis-wg@ietf.org, karp@ietf.org Subject: Re: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 18:04:25 -0000 Uma - It seems likely that we simply disagree. In summary as regards use of the extended sequence # in LSPs, I am saying you are trying to address a potential attack which is extremely unlikely to occur and for which, should it occur, the protocol already has a reliable means of recovering. I therefore feel this extension is not needed for LSPs. I will start another thread shortly regarding SNPs and hellos. Les > -----Original Message----- > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > Sent: Friday, March 30, 2012 3:13 AM > To: Les Ginsberg (ginsberg); Naiming Shen (naiming) > Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org > Subject: RE: [Isis-wg] Question regardingdraft-chunduri-isis-extended- > sequence-no-tlv-00 >=20 > Hi Les, >=20 > My replies in-line [Uma] > -- > Uma C. >=20 > > > > Uma - > > > > The response you make below does not address the points raised by Mike > and > > myself. It is understood that the difference between one version of a > > given LSP and another may be small or large > in terms > > of the number of TLVs that have changed. > > This point was not mentioned at all by Mike or myself. > > Here is a summary of the concerns we raised: > > 1)LSPs already have a built in sequence number which allows ISs to > recognize > > a valid but stale version of an LSP > > > > [Uma]: No, ISs can't recognize stale version, if this is replayed from > the > > previous session. I guess, we have clearly mentioned this in the > document. > > > This is not correct. > What happens is that the LSP with higher sequence number will get propagated > until it reaches the originator. > [Uma]: ... and all the node who processed and acted on this replay are > impacted. You can't precisely quantify, > how long and what impact. >=20 > The originator will recognize that this LSP is "owned" by itself but looks > "newer" (based on sequence #) > than what is in its local database. It will immediately generate a new > version of the LSP with higher > sequence # and flood that - which will replace any versions of the replayed > LSP which exist in the network. >=20 > [Uma]: Now you are talking about the recovery mechanism which is kicked in by > the originator in this situation. >=20 > Essentially you originally stated - "LSPs already have a built in sequence > number which allows ISs to > recognize a valid but stale version of an LSP". When I disagreed on this you > are talking about in built recovery mechanism. > I would only guess this is the gap, causing you to believe the new TLV which > allow you to recognize the replay and drop > has low ROI. >=20 > Depending on where in the network the attacker injects the replayed LSP will > influence the response time of the originating node - but the > replayed LSP will be replaced in a timely fashion without any extensions to > the protocol. >=20 > [Uma] Precisely. "Depending on where in the network" replayed LSP will > influence the response and in the mean time as I > said our FC timers kick-in all the nodes act on this replay (Eg: yeah, my > backlink check failed and removing all the prefixes > corresponding to the same). It's good this situation is recoverable > eventually, but the point is you are > already impacted. Not only you and *all_nodes* in the network are impacted ( > I mentioned this earlier and I am repeating). >=20 > Please consult ISO 10589 Section 7.3.15.1 (c) and (d) as well as Sections > 7.3.16.1 and 7.3.16.4. >=20 > > 2)Normal operation of the Update Process recovers from the presence of > a > > stale but valid LSP quickly (in tens to hundreds of milliseconds) by > having > > the originator regenerate its LSP with higher sequence #. This is a > scenario > > which is encountered in normal operation following a restart and is > handled > > correctly and promptly today. > > > > [Uma]: This need not be *always* TRUE. Of course, the above happens > only if > > the networks still has the restarted IS's LSP/LSP-fragments still not > aged > > out. >=20 > Agreed. > My point is only that the protocol handles this situation today and it can be > easily demonstrated. >=20 > > > > 3)The replay scenario discussed in the thread postulated that an > attacker > > could store many old LSPs and replay them one at a time. For this > attack to > > be possible all of the following conditions would need to be met: > > a) Attacker stores "many" LSPs without knowing whether a system will > ever > > restart and if it does when that restart will occur - which could be > months > > or years later > > b)A system shuts down and does not restart until all of its LSPs have > aged > > out of the network - which can be up to 18 hours depending on the > configured > > value for LSP Maxage > > c)After a system restarts the attacker recognizes that the system has > > restarted and replays each of the stored LSPs with some discrete time > > interval between replays Should all of the conditions be met it would > > still be true that the > replay of > > any version of a given LSP would only cause > > > > [Uma]: The above conditions are not impossible for an attacker (by > definition > > an adversary is absolutely motivated) >=20 > Agreed. > But my point is to highlight that an attack of this sort is unlikely to occur > and if it does the damage done will be short-lived and not persistent. >=20 > > > > a short disruption as the base protocol mechanisms mention in #2 above > would > > provide quick recovery. > > > > [Uma]: Again "short"?? I would only say it depends.. As I mentioned > earlier, > > in #2 you are assuming you always have the restarted IS's > LSP/LSP-fragments > > not aged out. >=20 > No - I am not making that assumption. I am saying that in order for the > attack to have any impact the restarted LSPs must have aged out. I think we > agree on that. >=20 > > After IS restart or brought back in service, for any potential > replay > > *all* nodes in the network have to flap the routes. > > This can happen multiple times to multiple LSP fragments > (depending on > > how these are replayed) and every time all nodes > > in the network are impacted which ever process the replay. > > > > All of the above raises the question as to whether extended sequence # > is > > needed in LSPs given the scenarios in which it adds any value at all > are > > severely limited and the value it adds is also limited i.e. the > protocol will > > recover even in the absence of the extended sequence number and will > do so > > quickly > > Could you please respond to the above? > > > > [Uma] Hope I clarified above and again the word "quickly" is > subjective in > > the example I provided. >=20 > The discussion I want to have is an evaluation of the "return on > investment(ROI)" of this extension. Every protocol extension comes with > costs. These include the costs of developing the extension, supporting the > extension, deploying the extension, and the overhead of processing the > extension in each PDU. The enthusiasm for any proposal is proportional to the > ROI. Right now, I am seeing a very low ROI in this case. >=20 > [Uma]: I would only say, just because we have an in-built recovery, you > can't assume a mechanism which mitigates this threat in first place has low > ROI. And coming to the solution, this optional TLV introduce neither > complexity nor introduce significant overhead in processing. So I didn't > quite understand your claim of "low" ROI. >=20 >=20 > Les >=20 > > > > There are then additional discussions to be had regarding the > usefulness of > > the extended sequence # in SNPs and hellos - but let's leave that to > another > > thread. > > > > [Uma] Sure, the additional discussion on the other messages are > equally > > important and we need your feedback/comments. > > > > > > Thanx. > > > > Les From uma.chunduri@ericsson.com Fri Mar 30 13:32:49 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E17721F85FC; Fri, 30 Mar 2012 13:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2iExKUxtkVI; Fri, 30 Mar 2012 13:32:48 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 455AF21F84DF; Fri, 30 Mar 2012 13:32:42 -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 q2UKWbFj016906; Fri, 30 Mar 2012 15:32:39 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 30 Mar 2012 16:32:38 -0400 From: Uma Chunduri To: "Les Ginsberg (ginsberg)" , "Naiming Shen (naiming)" Date: Fri, 30 Mar 2012 16:32:36 -0400 Thread-Topic: [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IAASsDLAAAU6AtA= Message-ID: References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.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 Cc: Mike Shand , "isis-wg@ietf.org" , "karp@ietf.org" Subject: Re: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 20:32:49 -0000 Hi Les, For Lsps, the return of investment is worth it or not, lets leave it to the= working group and the mainly=20 providers of the services to see, and we welcome your comments on other po= rtion of the doc. =20 --=20 Uma C.=20 -----Original Message----- From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]=20 Sent: Friday, March 30, 2012 11:04 AM To: Uma Chunduri; Naiming Shen (naiming) Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org Subject: RE: [Isis-wg] Question regardingdraft-chunduri-isis-extended-seque= nce-no-tlv-00 Uma - It seems likely that we simply disagree. In summary as regards use of the extended sequence # in LSPs, I am saying y= ou are trying to address a potential attack which is extremely unlikely to = occur and for which, should it occur, the protocol already has a reliable m= eans of recovering. I therefore feel this extension is not needed for LSPs. I will start another thread shortly regarding SNPs and hellos. Les > -----Original Message----- > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > Sent: Friday, March 30, 2012 3:13 AM > To: Les Ginsberg (ginsberg); Naiming Shen (naiming) > Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org > Subject: RE: [Isis-wg] Question regardingdraft-chunduri-isis-extended- > sequence-no-tlv-00 >=20 > Hi Les, >=20 > My replies in-line [Uma] > -- > Uma C. >=20 > > > > Uma - > > > > The response you make below does not address the points raised by Mike > and > > myself. It is understood that the difference between one version of a > > given LSP and another may be small or large > in terms > > of the number of TLVs that have changed. > > This point was not mentioned at all by Mike or myself. > > Here is a summary of the concerns we raised: > > 1)LSPs already have a built in sequence number which allows ISs to > recognize > > a valid but stale version of an LSP > > > > [Uma]: No, ISs can't recognize stale version, if this is replayed from > the > > previous session. I guess, we have clearly mentioned this in the > document. > > > This is not correct. > What happens is that the LSP with higher sequence number will get propagated > until it reaches the originator. > [Uma]: ... and all the node who processed and acted on this replay are=20 > impacted. You can't precisely quantify, how long and what impact. >=20 > The originator will recognize that this LSP is "owned" by itself but looks > "newer" (based on sequence #) > than what is in its local database. It will immediately generate a new=20 > version of the LSP with higher sequence # and flood that - which will=20 > replace any versions of the replayed > LSP which exist in the network. >=20 > [Uma]: Now you are talking about the recovery mechanism which is kicked in by > the originator in this situation. >=20 > Essentially you originally stated - "LSPs already have a built in sequence > number which allows ISs to > recognize a valid but stale version of an LSP". When I disagreed on this you > are talking about in built recovery mechanism. > I would only guess this is the gap, causing you to believe the new TLV which > allow you to recognize the replay and drop has low ROI. >=20 > Depending on where in the network the attacker injects the replayed LSP will > influence the response time of the originating node - but the replayed=20 > LSP will be replaced in a timely fashion without any extensions to > the protocol. >=20 > [Uma] Precisely. "Depending on where in the network" replayed LSP will=20 > influence the response and in the mean time as I said our FC timers=20 > kick-in all the nodes act on this replay (Eg: yeah, my > backlink check failed and removing all the prefixes corresponding to=20 > the same). It's good this situation is recoverable eventually, but the=20 > point is you are already impacted. Not only you and *all_nodes* in=20 > the network are impacted ( > I mentioned this earlier and I am repeating). >=20 > Please consult ISO 10589 Section 7.3.15.1 (c) and (d) as well as Sections > 7.3.16.1 and 7.3.16.4. >=20 > > 2)Normal operation of the Update Process recovers from the presence of > a > > stale but valid LSP quickly (in tens to hundreds of milliseconds) by > having > > the originator regenerate its LSP with higher sequence #. This is a > scenario > > which is encountered in normal operation following a restart and is > handled > > correctly and promptly today. > > > > [Uma]: This need not be *always* TRUE. Of course, the above happens > only if > > the networks still has the restarted IS's LSP/LSP-fragments still not > aged > > out. >=20 > Agreed. > My point is only that the protocol handles this situation today and it can be > easily demonstrated. >=20 > > > > 3)The replay scenario discussed in the thread postulated that an > attacker > > could store many old LSPs and replay them one at a time. For this > attack to > > be possible all of the following conditions would need to be met: > > a) Attacker stores "many" LSPs without knowing whether a system will > ever > > restart and if it does when that restart will occur - which could be > months > > or years later > > b)A system shuts down and does not restart until all of its LSPs have > aged > > out of the network - which can be up to 18 hours depending on the > configured > > value for LSP Maxage > > c)After a system restarts the attacker recognizes that the system has > > restarted and replays each of the stored LSPs with some discrete time > > interval between replays Should all of the conditions be met it would > > still be true that the > replay of > > any version of a given LSP would only cause > > > > [Uma]: The above conditions are not impossible for an attacker (by > definition > > an adversary is absolutely motivated) >=20 > Agreed. > But my point is to highlight that an attack of this sort is unlikely to occur > and if it does the damage done will be short-lived and not persistent. >=20 > > > > a short disruption as the base protocol mechanisms mention in #2 above > would > > provide quick recovery. > > > > [Uma]: Again "short"?? I would only say it depends.. As I mentioned > earlier, > > in #2 you are assuming you always have the restarted IS's > LSP/LSP-fragments > > not aged out. >=20 > No - I am not making that assumption. I am saying that in order for the > attack to have any impact the restarted LSPs must have aged out. I think we > agree on that. >=20 > > After IS restart or brought back in service, for any potential > replay > > *all* nodes in the network have to flap the routes. > > This can happen multiple times to multiple LSP fragments > (depending on > > how these are replayed) and every time all nodes > > in the network are impacted which ever process the replay. > > > > All of the above raises the question as to whether extended sequence # > is > > needed in LSPs given the scenarios in which it adds any value at all > are > > severely limited and the value it adds is also limited i.e. the > protocol will > > recover even in the absence of the extended sequence number and will > do so > > quickly > > Could you please respond to the above? > > > > [Uma] Hope I clarified above and again the word "quickly" is > subjective in > > the example I provided. >=20 > The discussion I want to have is an evaluation of the "return on=20 > investment(ROI)" of this extension. Every protocol extension comes with > costs. These include the costs of developing the extension, supporting the > extension, deploying the extension, and the overhead of processing the=20 > extension in each PDU. The enthusiasm for any proposal is proportional to the > ROI. Right now, I am seeing a very low ROI in this case. >=20 > [Uma]: I would only say, just because we have an in-built recovery, you > can't assume a mechanism which mitigates this threat in first place has low > ROI. And coming to the solution, this optional TLV introduce neither=20 > complexity nor introduce significant overhead in processing. So I didn't > quite understand your claim of "low" ROI. >=20 >=20 > Les >=20 > > > > There are then additional discussions to be had regarding the > usefulness of > > the extended sequence # in SNPs and hellos - but let's leave that to > another > > thread. > > > > [Uma] Sure, the additional discussion on the other messages are > equally > > important and we need your feedback/comments. > > > > > > Thanx. > > > > Les From manav.bhatia@alcatel-lucent.com Fri Mar 30 19:34:13 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0617821F858F; Fri, 30 Mar 2012 19:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.557 X-Spam-Level: X-Spam-Status: No, score=-8.557 tagged_above=-999 required=5 tests=[AWL=1.442, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naaPbA+vv1BW; Fri, 30 Mar 2012 19:34:11 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6061B21F858A; Fri, 30 Mar 2012 19:34:11 -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 q2V2Y3Ys004476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Mar 2012 21:34:06 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2V2Y1xb010517 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 31 Mar 2012 08:04:01 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Sat, 31 Mar 2012 08:04:01 +0530 From: "Bhatia, Manav (Manav)" To: "Les Ginsberg (ginsberg)" , Uma Chunduri , "Naiming Shen (naiming)" Date: Sat, 31 Mar 2012 08:04:00 +0530 Thread-Topic: [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IAASsDLAABHQm4A= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02E41D5C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.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.33 Cc: Mike Shand , "isis-wg@ietf.org" , "karp@ietf.org" Subject: Re: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 02:34:13 -0000 And this is precisely the reason why crypto sequence numbers were not added= when we did RFC 5310. Cheers, Manav > -----Original Message----- > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On=20 > Behalf Of Les Ginsberg (ginsberg) > Sent: Friday, March 30, 2012 11:34 PM > To: Uma Chunduri; Naiming Shen (naiming) > Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org > Subject: Re: [karp] [Isis-wg] Question=20 > regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 >=20 > Uma - >=20 > It seems likely that we simply disagree. >=20 > In summary as regards use of the extended sequence # in LSPs,=20 > I am saying you are trying to address a potential attack=20 > which is extremely unlikely to occur and for which, should it=20 > occur, the protocol already has a reliable means of=20 > recovering. I therefore feel this extension is not needed for LSPs. >=20 > I will start another thread shortly regarding SNPs and hellos. >=20 > Les >=20 >=20 > > -----Original Message----- > > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > > Sent: Friday, March 30, 2012 3:13 AM > > To: Les Ginsberg (ginsberg); Naiming Shen (naiming) > > Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org > > Subject: RE: [Isis-wg] Question=20 > regardingdraft-chunduri-isis-extended- > > sequence-no-tlv-00 > >=20 > > Hi Les, > >=20 > > My replies in-line [Uma] > > -- > > Uma C. > >=20 > > > > > > Uma - > > > > > > The response you make below does not address the points raised by > Mike > > and > > > myself. It is understood that the difference between one=20 > version of > a > > > given LSP and another may be small or large > > in terms > > > of the number of TLVs that have changed. > > > This point was not mentioned at all by Mike or myself. > > > Here is a summary of the concerns we raised: > > > 1)LSPs already have a built in sequence number which allows ISs to > > recognize > > > a valid but stale version of an LSP > > > > > > [Uma]: No, ISs can't recognize stale version, if this is replayed > from > > the > > > previous session. I guess, we have clearly mentioned this in the > > document. > > > > > This is not correct. > > What happens is that the LSP with higher sequence number will get > propagated > > until it reaches the originator. > > [Uma]: ... and all the node who processed and acted on this=20 > replay are=20 > > impacted. You can't precisely quantify, how long and what impact. > >=20 > > The originator will recognize that this LSP is "owned" by itself but > looks > > "newer" (based on sequence #) > > than what is in its local database. It will immediately=20 > generate a new=20 > > version of the LSP with higher sequence # and flood that -=20 > which will=20 > > replace any versions of the > replayed > > LSP which exist in the network. > >=20 > > [Uma]: Now you are talking about the recovery mechanism which is > kicked in by > > the originator in this situation. > >=20 > > Essentially you originally stated - "LSPs already have a built in > sequence > > number which allows ISs to > > recognize a valid but stale version of an LSP". When I disagreed on > this you > > are talking about in built recovery mechanism. > > I would only guess this is the gap, causing you to believe=20 > the new TLV > which > > allow you to recognize the replay and drop has low ROI. > >=20 > > Depending on where in the network the attacker injects the replayed > LSP will > > influence the response time of the originating node - but=20 > the replayed=20 > > LSP will be replaced in a timely fashion without any > extensions to > > the protocol. > >=20 > > [Uma] Precisely. "Depending on where in the network"=20 > replayed LSP will=20 > > influence the response and in the mean time as I said our FC timers=20 > > kick-in all the nodes act on this replay (Eg: yeah, > my > > backlink check failed and removing all the prefixes=20 > corresponding to=20 > > the same). It's good this situation is recoverable=20 > eventually, but the=20 > > point is you are already impacted. Not only you and *all_nodes* in=20 > > the network are > impacted ( > > I mentioned this earlier and I am repeating). > >=20 > > Please consult ISO 10589 Section 7.3.15.1 (c) and (d) as well as > Sections > > 7.3.16.1 and 7.3.16.4. > >=20 > > > 2)Normal operation of the Update Process recovers from=20 > the presence > of > > a > > > stale but valid LSP quickly (in tens to hundreds of=20 > milliseconds) by > > having > > > the originator regenerate its LSP with higher sequence #.=20 > This is a > > scenario > > > which is encountered in normal operation following a=20 > restart and is > > handled > > > correctly and promptly today. > > > > > > [Uma]: This need not be *always* TRUE. Of course, the=20 > above happens > > only if > > > the networks still has the restarted IS's LSP/LSP-fragments still > not > > aged > > > out. > >=20 > > Agreed. > > My point is only that the protocol handles this situation=20 > today and it > can be > > easily demonstrated. > >=20 > > > > > > 3)The replay scenario discussed in the thread postulated that an > > attacker > > > could store many old LSPs and replay them one at a time. For this > > attack to > > > be possible all of the following conditions would need to be met: > > > a) Attacker stores "many" LSPs without knowing whether a=20 > system will > > ever > > > restart and if it does when that restart will occur -=20 > which could be > > months > > > or years later > > > b)A system shuts down and does not restart until all of its LSPs > have > > aged > > > out of the network - which can be up to 18 hours depending on the > > configured > > > value for LSP Maxage > > > c)After a system restarts the attacker recognizes that the system > has > > > restarted and replays each of the stored LSPs with some discrete > time > > > interval between replays Should all of the conditions be met it > would > > > still be true that the > > replay of > > > any version of a given LSP would only cause > > > > > > [Uma]: The above conditions are not impossible for an attacker (by > > definition > > > an adversary is absolutely motivated) > >=20 > > Agreed. > > But my point is to highlight that an attack of this sort is unlikely > to occur > > and if it does the damage done will be short-lived and not=20 > persistent. > >=20 > > > > > > a short disruption as the base protocol mechanisms mention in #2 > above > > would > > > provide quick recovery. > > > > > > [Uma]: Again "short"?? I would only say it depends.. As I=20 > mentioned > > earlier, > > > in #2 you are assuming you always have the restarted IS's > > LSP/LSP-fragments > > > not aged out. > >=20 > > No - I am not making that assumption. I am saying that in order for > the > > attack to have any impact the restarted LSPs must have aged out. I > think we > > agree on that. > >=20 > > > After IS restart or brought back in service, for any > potential > > replay > > > *all* nodes in the network have to flap the routes. > > > This can happen multiple times to multiple LSP fragments > > (depending on > > > how these are replayed) and every time all nodes > > > in the network are impacted which ever process the replay. > > > > > > All of the above raises the question as to whether=20 > extended sequence > # > > is > > > needed in LSPs given the scenarios in which it adds any=20 > value at all > > are > > > severely limited and the value it adds is also limited i.e. the > > protocol will > > > recover even in the absence of the extended sequence=20 > number and will > > do so > > > quickly > > > Could you please respond to the above? > > > > > > [Uma] Hope I clarified above and again the word "quickly" is > > subjective in > > > the example I provided. > >=20 > > The discussion I want to have is an evaluation of the "return on=20 > > investment(ROI)" of this extension. Every protocol extension comes > with > > costs. These include the costs of developing the extension,=20 > supporting > the > > extension, deploying the extension, and the overhead of=20 > processing the=20 > > extension in each PDU. The enthusiasm for any proposal is=20 > proportional > to the > > ROI. Right now, I am seeing a very low ROI in this case. > >=20 > > [Uma]: I would only say, just because we have an in-built recovery, > you > > can't assume a mechanism which mitigates this threat in first place > has low > > ROI. And coming to the solution, this optional TLV=20 > introduce neither=20 > > complexity nor introduce significant overhead in processing. So I > didn't > > quite understand your claim of "low" ROI. > >=20 > >=20 > > Les > >=20 > > > > > > There are then additional discussions to be had regarding the > > usefulness of > > > the extended sequence # in SNPs and hellos - but let's=20 > leave that to > > another > > > thread. > > > > > > [Uma] Sure, the additional discussion on the other messages are > > equally > > > important and we need your feedback/comments. > > > > > > > > > Thanx. > > > > > > Les > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > = From manav.bhatia@alcatel-lucent.com Fri Mar 30 19:39:54 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A81221F8565; Fri, 30 Mar 2012 19:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.879 X-Spam-Level: X-Spam-Status: No, score=-8.879 tagged_above=-999 required=5 tests=[AWL=1.720, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWEVD+uKvIrt; Fri, 30 Mar 2012 19:39:54 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0969E21F854F; Fri, 30 Mar 2012 19:39:53 -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 q2V2dlCn008179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Mar 2012 21:39:49 -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 q2V2dfLI028211 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 31 Mar 2012 08:09:41 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 31 Mar 2012 08:09:41 +0530 From: "Bhatia, Manav (Manav)" To: Uma Chunduri , "Les Ginsberg (ginsberg)" , "Naiming Shen (naiming)" Date: Sat, 31 Mar 2012 08:09:44 +0530 Thread-Topic: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IAAkpaZw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02E41D5D@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.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: Mike Shand , "isis-wg@ietf.org" , "karp@ietf.org" Subject: Re: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 02:39:54 -0000 Hi Uma, =20 > [Uma]: I would only say, just because we have an in-built=20 > recovery, you can't assume a mechanism which mitigates this=20 > threat in first place has low ROI. And coming to the=20 > solution, this optional TLV introduce neither complexity nor=20 > introduce significant overhead in processing. So I didn't=20 > quite understand your claim of "low" ROI. Well it does introduce an additional burden on the vendors to implement and= test this feature. It also places a huge burden on operators to see the im= pact of deploying this feature. There is no flag day where all routers are = upgraded with the new image and you might have to deal with cases where the= re is a mix of routers that support and don't support this feature. You wil= l have to define some mechanism on how this needs to work. I don't say its = unachievable - I am trying to tell you what Les could possibly be alluding = to when he mentions "low" ROI. Cheers, Manav From ginsberg@cisco.com Fri Mar 30 20:48:29 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE821F8562; Fri, 30 Mar 2012 20:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3th6XlLXtxV; Fri, 30 Mar 2012 20:48:28 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7710A21F855F; Fri, 30 Mar 2012 20:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=3006; q=dns/txt; s=iport; t=1333165708; x=1334375308; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=sMj8tA7YKzMNeTYvTjlflccjaf2YDpPZ6AusOTHfmWI=; b=XTK60gkCHTyo6pXmGh++DuaUFuhuJXKkULa1HLwNQDM3IfLnawsVUN8G /MmdYOEiT5E5Bv35C8oWnqDvpSOhoJz9lpH32MHliCoFKy7C5fe7wEJeX 4iW3ZXH6cpig1Npvx8wJDbl1zfIC6mOVxluALZLmGwru6Wtvn5ZaQ/vqO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGB+dk+rRDoJ/2dsb2JhbABFuHmBB4IJAQEBBBIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAgQBEggTB4dmAZtBnnKLEoUfYwSIWJtQgWiDB4E2 X-IronPort-AV: E=Sophos;i="4.75,347,1330905600"; d="scan'208";a="35893855" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 31 Mar 2012 03:48:11 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2V3mBnb005574; Sat, 31 Mar 2012 03:48:11 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 20:48:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2012 20:48:09 -0700 Message-ID: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D02E41D5D@INBANSXCHMBSA1.in.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 Thread-Index: AcyVD3r+AHoMB7E2R0+4FJMQgKrozAAACfDQHh1xsYAAGkt94AAFMrTQAAJooMAAEcn4IAAkpaZwAAF6EGA= References: <4F31FB49-B9B2-492E-BC9E-A32986E4BCF0@cisco.com><4EA9D09A.6070206@googlemail.com> <7C 362EEF9C7896468B36C9B79200D8350D02E41D5D@INBANSXCHMBSA1.in.alcatel-lucent.com> From: "Les Ginsberg (ginsberg)" To: "Bhatia, Manav (Manav)" , "Uma Chunduri" , "Naiming Shen (naiming)" X-OriginalArrivalTime: 31 Mar 2012 03:48:11.0319 (UTC) FILETIME=[17D27C70:01CD0EF1] Cc: Mike Shand , isis-wg@ietf.org, karp@ietf.org Subject: Re: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 03:48:29 -0000 Indeed, the deployment issues are another thing that is troubling - especially in the case of LSPs. I don't think this extension can be safely enabled for LSPs unless all routers in the network support it. Consider this simple example: R1----R2----R3 R1 does NOT support the extension, but R2 and R3 do support the extension. All routers have an LSP originated by R3 - call it R3.00-00 Seq #10 ESSN # 50 An attacker has an old LSP from a previous incarnation of R3. Call it R3.00-00 Seq #20 ESSN # 40. =20 The attacker injects this replayed LSP into the network at R1. As the sequence # is greater than the copy in the local database R1 accepts the replayed LSP and then floods it to R2. R2 however rejects the replayed LSP because it has an older ESSN #. LSPDB is now inconsistent between R1 and R2/R3. This condition will persist until R3 generates a new LSP with sequence # > 20 or until the replayed LSP on R1 ages out. I think there are similar constraints as regards the use of the extension in IIHs and SNPs - though in that case it is only necessary to upgrade all routers on a particular link - and probably support enabling the extension on a per link basis. Note that if not all ISs on a LAN segment support the extension, then a replay attack could result in an inconsistent set of neighbors and multiple DISs might be elected, rendering the LAN unreliable for forwarding. There may be ways to protect against the perils of partial deployment - which it would be good if the draft addressed - but I do think full deployment is required for the feature to be enabled. Les > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Friday, March 30, 2012 7:40 PM > To: Uma Chunduri; Les Ginsberg (ginsberg); Naiming Shen (naiming) > Cc: Mike Shand; isis-wg@ietf.org; karp@ietf.org > Subject: RE: [karp] [Isis-wg] Question regardingdraft-chunduri-isis-extended- > sequence-no-tlv-00 >=20 > Hi Uma, >=20 > > [Uma]: I would only say, just because we have an in-built > > recovery, you can't assume a mechanism which mitigates this > > threat in first place has low ROI. And coming to the > > solution, this optional TLV introduce neither complexity nor > > introduce significant overhead in processing. So I didn't > > quite understand your claim of "low" ROI. >=20 > Well it does introduce an additional burden on the vendors to implement and > test this feature. It also places a huge burden on operators to see the > impact of deploying this feature. There is no flag day where all routers are > upgraded with the new image and you might have to deal with cases where there > is a mix of routers that support and don't support this feature. You will > have to define some mechanism on how this needs to work. I don't say its > unachievable - I am trying to tell you what Les could possibly be alluding to > when he mentions "low" ROI. >=20 > Cheers, Manav