From hartmans@mit.edu Tue Mar 1 05:35:05 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C583A69EE for ; Tue, 1 Mar 2011 05:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.021 X-Spam-Level: X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21+UFI58I0xT for ; Tue, 1 Mar 2011 05:35:05 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 5FCAE3A725B for ; Tue, 1 Mar 2011 05:33:54 -0800 (PST) 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 C11C32010F; Tue, 1 Mar 2011 08:32:24 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 49A884307; Tue, 1 Mar 2011 08:34:50 -0500 (EST) From: Sam Hartman To: "Joel M. Halpern" References: <4D6C2164.8020308@joelhalpern.com> Date: Tue, 01 Mar 2011 08:34:50 -0500 In-Reply-To: <4D6C2164.8020308@joelhalpern.com> (Joel M. Halpern's message of "Mon, 28 Feb 2011 17:27:48 -0500") 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: "karp@ietf.org" Subject: Re: [karp] WG Last Call: draft-ietf-karp-design-guide-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Mar 2011 13:35:06 -0000 I support publication of this document as informational thinking on where we are now. We haven't had a lot of experience with the process described in this document for the phased approach and for the deliverables at each stage. I think it's fine to snapshot our progress now, and move on with actually doing the work. I don't think we have enough confidence in this document that we should be rigidly bound by it. I agree it represents our current thinking. However, I'd like to retain flexibility to make possibly significant changes to the details of the process as we get more experience. So, if the purpose of publishing this is to describe where we are that's great. If the purpose is to close off refinements of the process we're going to use then I think it is premature. Note that our charter does have constraints on the process we're going to use; I support those constraints. From hartmans@mit.edu Tue Mar 1 06:17:43 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03653A6810; Tue, 1 Mar 2011 06:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.979 X-Spam-Level: X-Spam-Status: No, score=-102.979 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhzBmqBwBHmV; Tue, 1 Mar 2011 06:17:43 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 4080C3A680C; Tue, 1 Mar 2011 06:17:43 -0800 (PST) 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 0258C2011F; Tue, 1 Mar 2011 09:16:14 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7665B4307; Tue, 1 Mar 2011 09:18:39 -0500 (EST) From: Sam Hartman To: Michael Barnes References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3029F7.6040107@cisco.com> <4D3720F2.70301@cisco.com> <4D372F7B.9030507@cisco.com> <4D6C567D.5030501@cisco.com> Date: Tue, 01 Mar 2011 09:18:39 -0500 In-Reply-To: <4D6C567D.5030501@cisco.com> (Michael Barnes's message of "Mon, 28 Feb 2011 18:14:21 -0800") 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: "karp@ietf.org" , Sam Hartman , "ospf@ietf.org" Subject: Re: [karp] Security Extension for OSPFv2 when using Manual Key Management X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Mar 2011 14:17:44 -0000 Hi. Thanks for pointing out that I failed to consider packet hashing delays as a function of packet size. I feel kind of silly. I think the highest order of business is figuring out whether we want an approach based on exchanging nonces to prove freshness or an approach based on nonvolatile boot counts. To me, the biggest question there is what attacks are possible if you cannot guarantee freshness. As I've said, I'm reasonably sure you can get an adjacency to 2-way state. However that doesn't seem to be very useful as an attack. If we do think freshness is important, I now agree it makes sense to consider an option that involves challenge packets. (It might also be possible to trim the hello information in our current proposal so that in steady state the hello sizes do not increase significantly.) Thanks again for working with me until I understood your point. From glen.kent@gmail.com Wed Mar 2 08:07:45 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5F43A6816 for ; Wed, 2 Mar 2011 08:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I06bgHF8QmI1 for ; Wed, 2 Mar 2011 08:07:44 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 637113A67AE for ; Wed, 2 Mar 2011 08:07:44 -0800 (PST) Received: by vws6 with SMTP id 6so63046vws.31 for ; Wed, 02 Mar 2011 08:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VeKh8kOY6p0IAUeI2GbvMN5mZZmlti9snM0/dJvKIO0=; b=g2wX9rNWFUooFrpaIdMqxTo/7v1S9ubArdsWhyG0rYtxhUzQT5XVz4sKVBxn9D0nv8 HVarsG4aJs5NAx4gY5CQNcfbb2oZLlw69abIuLqiebYLgESZsVTNtxmYyP+fpxplLAEb u/s8+kpiFRD0zzV529xn1SHFmJekAn75q/eMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oIWFRybCyUuzZuRcS2i39OsWE9CP7sgBGySMQ76U22KfmKdcqjvrLy6YysBDGIUCnC gPf57i6vDzHfD2W5+3vdckl8lHxoRmpxk+L0ozrCSn4xI5fOtwFZCFMs4N6hEzMoZ5SN Q6VjkyyUYHeh4rElpChyn/O5VeLPjMmNHeBqI= MIME-Version: 1.0 Received: by 10.52.18.36 with SMTP id t4mr3529350vdd.285.1299082130107; Wed, 02 Mar 2011 08:08:50 -0800 (PST) Received: by 10.52.158.33 with HTTP; Wed, 2 Mar 2011 08:08:50 -0800 (PST) In-Reply-To: <4D6C2164.8020308@joelhalpern.com> References: <4D6C2164.8020308@joelhalpern.com> Date: Wed, 2 Mar 2011 21:38:50 +0530 Message-ID: From: Glen Kent To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "karp@ietf.org" Subject: Re: [karp] WG Last Call: draft-ietf-karp-design-guide-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Mar 2011 16:07:45 -0000 Support! On Tue, Mar 1, 2011 at 3:57 AM, Joel M. Halpern wrote= : > This document: > http://datatracker.ietf.org/doc/draft-ietf-karp-design-guide/ > Keying and Authentication for Routing Protocols (KARP) Design Guidelines > is a working group document. =A0It is a charter deliverable. =A0There hav= e been > no comments or discussion recently. > > The chairs are therefore asking for a WG last call, with the view of send= ing > this to our AD for publication as an Informational RFC > > Yours, > Joel M. Halpern > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From glen.kent@gmail.com Wed Mar 2 08:07:45 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C57B3A67AE for ; Wed, 2 Mar 2011 08:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOouGUgwqbCr for ; Wed, 2 Mar 2011 08:07:44 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id A288F3A6810 for ; Wed, 2 Mar 2011 08:07:44 -0800 (PST) Received: by vxg33 with SMTP id 33so88200vxg.31 for ; Wed, 02 Mar 2011 08:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x9LICCh7Oj2l2H6eav0UNOVHL0lUPs/4ADTZ+xeBrrI=; b=l/27rlh7xkW+VAQNqM2OqWTb5r4L//mJGNtmNf4Hws/QjHWgJklsM1g5Kw8XETmNbJ GGbCPX0kyYIPYiV2r541rGuOAw11MEAB3AQIt0pf5TePqRpn0kQBjCLzdbrhwRuwwJTc TuUq1F3fMh6y+eJjl+IBF/vF+N4o2pV5A5GLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Wn4igs14ayojtYa0flFiTqVTLi2nQ5fKJpylRGVeROphkIl1jU6gPFv6vr4ouXWv7Y TlFV9/7Gqhd1wNwnov7IOybcI7qRiTx4VfNIAWIAzWSmcG4rpPebjO1/JHvBfCi5flF4 Jr/4EYX8iU3QwaJtCqWS8hehBap2zo61lbpzk= MIME-Version: 1.0 Received: by 10.52.168.201 with SMTP id zy9mr4642655vdb.85.1299082090283; Wed, 02 Mar 2011 08:08:10 -0800 (PST) Received: by 10.52.158.33 with HTTP; Wed, 2 Mar 2011 08:08:10 -0800 (PST) In-Reply-To: <4D6C2254.5000602@joelhalpern.com> References: <4D6C2254.5000602@joelhalpern.com> Date: Wed, 2 Mar 2011 21:38:10 +0530 Message-ID: From: Glen Kent To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "karp@ietf.org" Subject: Re: [karp] WG LC: draft-ietf-karp-threats-reqs-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Mar 2011 16:07:45 -0000 Support! On Tue, Mar 1, 2011 at 4:01 AM, Joel M. Halpern wrote= : > This document: > http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ > The Threat Analysis and Requirements for Cryptographic Authentication of > Routing Protocols' Transports > is a working group document. =A0It is a charter deliverable. =A0There hav= e been > no comments or discussion recently. > > The chairs are therefore asking for a WG last call, with the view of send= ing > this to our AD for publication as an Proposed Standard RFC. > This Last Call will last 2 weeks, ending at the end of the day March 14th= . > > Yours, > Joel (and Brian) > > PS: which is how I should have signed the last one. =A0Sorry, bad habits. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From zhangdacheng@huawei.com Wed Mar 2 18:11:02 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045323A6920 for ; Wed, 2 Mar 2011 18:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kI52QSbMfXYc for ; Wed, 2 Mar 2011 18:10:59 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6179A3A6927 for ; Wed, 2 Mar 2011 18:10:58 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHG00J41M3UWM@szxga04-in.huawei.com> for karp@ietf.org; Thu, 03 Mar 2011 10:11:55 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHG000RDM3UID@szxga04-in.huawei.com> for karp@ietf.org; Thu, 03 Mar 2011 10:11:54 +0800 (CST) Received: from z00133208z ([10.110.98.43]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHG00ENKM3RCJ@szxml06-in.huawei.com> for karp@ietf.org; Thu, 03 Mar 2011 10:11:54 +0800 (CST) Date: Thu, 03 Mar 2011 10:11:51 +0800 From: Dacheng Zhang In-reply-to: To: karp@ietf.org Message-id: <01fd01cbd948$5c0cda50$14268ef0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=UTF-8 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcvY9FM4Eik3DzViQ/uj4TzGW5HAzgAU/tIQ References: <4D6C2164.8020308@joelhalpern.com> Subject: Re: [karp] WG Last Call: draft-ietf-karp-design-guide-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 02:11:03 -0000 +1 ^_^ >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: karp-bounces@ietf.org = [mailto:karp-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Glen >> Kent >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2011=E5=B9=B43=E6=9C=883=E6=97=A5 0:09 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Joel M. Halpern >> =E6=8A=84=E9=80=81: karp@ietf.org >> =E4=B8=BB=E9=A2=98: Re: [karp] WG Last Call: = draft-ietf-karp-design-guide-01 >>=20 >> Support! >>=20 >> On Tue, Mar 1, 2011 at 3:57 AM, Joel M. Halpern >> wrote: >> > This document: >> > http://datatracker.ietf.org/doc/draft-ietf-karp-design-guide/ >> > Keying and Authentication for Routing Protocols (KARP) Design = Guidelines >> > is a working group document. It is a charter deliverable. There = have >> been >> > no comments or discussion recently. >> > >> > The chairs are therefore asking for a WG last call, with the view = of sending >> > this to our AD for publication as an Informational RFC >> > >> > Yours, >> > Joel M. Halpern >> > _______________________________________________ >> > 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 zhangdacheng@huawei.com Wed Mar 2 18:11:50 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134263A6927 for ; Wed, 2 Mar 2011 18:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=-2.114, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7+sFVB40c07 for ; Wed, 2 Mar 2011 18:11:49 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3A38D3A6921 for ; Wed, 2 Mar 2011 18:11:49 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHG00A9OM3PP3@szxga05-in.huawei.com> for karp@ietf.org; Thu, 03 Mar 2011 10:11:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHG004RSM3PYY@szxga05-in.huawei.com> for karp@ietf.org; Thu, 03 Mar 2011 10:11:49 +0800 (CST) Received: from z00133208z ([10.110.98.43]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHG00EDYM33CJ@szxml06-in.huawei.com> for karp@ietf.org; Thu, 03 Mar 2011 10:11:49 +0800 (CST) Date: Thu, 03 Mar 2011 10:11:25 +0800 From: Dacheng Zhang In-reply-to: To: karp@ietf.org Message-id: <01fc01cbd948$4e41f810$eac5e830$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=UTF-8 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcvY9E1C/fKhGWJIQrSKc1Rb00SJWwAU+UtQ References: <4D6C2254.5000602@joelhalpern.com> Subject: Re: [karp] WG LC: draft-ietf-karp-threats-reqs-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 02:11:50 -0000 +1 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: karp-bounces@ietf.org = [mailto:karp-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Glen >> Kent >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2011=E5=B9=B43=E6=9C=883=E6=97=A5 0:08 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Joel M. Halpern >> =E6=8A=84=E9=80=81: karp@ietf.org >> =E4=B8=BB=E9=A2=98: Re: [karp] WG LC: draft-ietf-karp-threats-reqs-01 >>=20 >> Support! >>=20 >> On Tue, Mar 1, 2011 at 4:01 AM, Joel M. Halpern >> wrote: >> > This document: >> > http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ >> > The Threat Analysis and Requirements for Cryptographic = Authentication of >> > Routing Protocols' Transports >> > is a working group document. It is a charter deliverable. There = have >> been >> > no comments or discussion recently. >> > >> > The chairs are therefore asking for a WG last call, with the view = of sending >> > this to our AD for publication as an Proposed Standard RFC. >> > This Last Call will last 2 weeks, ending at the end of the day = March 14th. >> > >> > Yours, >> > Joel (and Brian) >> > >> > PS: which is how I should have signed the last one. Sorry, bad = habits. >> > _______________________________________________ >> > 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 rja.lists@gmail.com Thu Mar 3 08:12:48 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 036EB3A6A04 for ; Thu, 3 Mar 2011 08:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.453 X-Spam-Level: X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DstFcRyaI8Yk for ; Thu, 3 Mar 2011 08:12:47 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 2ECE23A69ED for ; Thu, 3 Mar 2011 08:12:47 -0800 (PST) Received: by qyk29 with SMTP id 29so12183qyk.10 for ; Thu, 03 Mar 2011 08:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=LbpikIwNnuA8UoZCuopQfkqZF/Jhoiqgr/17WfxftWc=; b=fLY1wD/HBqkZrWIZgrJHSWIv80h0nglXfDd2VpeYhsPiPiYNF1MA4pIyGDwgmBv2AG 2J+0mREhwaOciLk8oSvY5zYGBM1JsXPAgOLUNcREGCU1eTmAWhfPfndKnNY/VRVUz/OU MO9T6pt4nv2i8wmPxjZ5r1QkWwHFFpE4TTluo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=gdvf+X5p7Zr6+8sO4KIJ4RVVbn5Fz3dD0Rv2VFKmspnijRQ4bY8A2G4QKG9uFq+0zZ GJ7ZI+0z0mKqSN6X2SSflL2Cp/CFedfUCKVqe/WXIgHtBWr5G9MxCPYhDnpRMAoDf0pp 0z9y/8fqMUJOHQZ6jcSKTDIzhgDwl1Z/4FugA= Received: by 10.224.214.193 with SMTP id hb1mr1193362qab.372.1299168834679; Thu, 03 Mar 2011 08:13:54 -0800 (PST) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id s10sm914764qco.47.2011.03.03.08.13.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Mar 2011 08:13:53 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 Mar 2011 11:13:52 -0500 Message-Id: <55F5656F-F54A-48BE-92BE-58715F9763AE@gmail.com> To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: Re: [karp] WG Last Call: draft-ietf-karp-design-guide-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 16:12:48 -0000 Earlier, Sam Hartman wrote: > I don't think we have enough confidence in this document > that we should be rigidly bound by it. > > I agree it represents our current thinking. > > However, I'd like to retain flexibility to make possibly significant > changes to the details of the process as we get more experience. > > So, if the purpose of publishing this is to describe > where we are that's great. > > If the purpose is to close off refinements of the process > [that] we're going to use then I think it is premature. +1 It is useful to document current thinking. I don't have sufficient confidence in the document that the WG ought to be rigidly bound by it. For example, if some (e.g. future) proposal appears, conformance to this document by that proposal ought NOT be required before that proposal receives full and due consideration by the WG on the proposal's own merits. Yours, Ran From rja.lists@gmail.com Thu Mar 3 08:19:12 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6313A69A1 for ; Thu, 3 Mar 2011 08:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noWGMuA8QYID for ; Thu, 3 Mar 2011 08:19:11 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 48DE53A6830 for ; Thu, 3 Mar 2011 08:19:11 -0800 (PST) Received: by vws6 with SMTP id 6so1257556vws.31 for ; Thu, 03 Mar 2011 08:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=zoLbDy8JPXGSvGAixkceWkxvcQ2UqU0N2+p2hyf4CFI=; b=KKfZBbXM4pYpth+Ypx9M+9JFawEPKVrtNCyGuluMycBSUoGKInJvAUdqa22dScp04i /KNzxabERTD6/hBFEXqC7xYww0hJMzToJItSgOmlFz2NeIhkj8JpON7neSRmLOk8jww9 TXbZhgjje9LxyAZ+nHKfhdQf55VkDYIwcvF4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=aUu7Yoy/pE53AHuPtBzYZspkkvVZo9V6Ul9q/magEC6zm7ecoC3z6QqX6Aim85ZKPZ zeHRrd88emKV1wixEjMdZ8SugnM7OPy+wUQ/DYKwV8SRXEPJvQMFb33z0zXtv9zEy8O7 Im4pZhaY/TF6YYLxpqi65VudTsoDLIfbCvTTQ= Received: by 10.52.176.163 with SMTP id cj3mr2091606vdc.23.1299169218597; Thu, 03 Mar 2011 08:20:18 -0800 (PST) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id eo11sm125642vcb.27.2011.03.03.08.20.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Mar 2011 08:20:18 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 Mar 2011 11:20:16 -0500 Message-Id: <1AAA22C4-AB28-45AF-8B1F-67B39CEE3F1A@gmail.com> To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: Re: [karp] WG LC: draft-ietf-karp-threats-reqs-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 16:19:12 -0000 While I think it worthwhile to document current thinking, I also lack sufficient confidence in this document to use its "requirements" as mandatory requirements for the KARP WG. As proposals appear to this WG, proposals ought to be evaluated on their own merits by the whole WG, even if those proposals do not fully meet all the specified "requirements" contained in this document. Separately, we normally reserve "PROPOSED STANDARD" for something that can be either implemented, deployed, or both. Requirements documents usually get published as either INFORMATIONAL or BCP. As such, for each of the above reasons separately, I think this document can go out now, but ought to go out with INFORMATIONAL status, and NOT PROPOSED STANDARD status. Yours, Ran From manav.bhatia@alcatel-lucent.com Sun Mar 6 16:44:00 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C21228C0DF for ; Sun, 6 Mar 2011 16:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.826 X-Spam-Level: X-Spam-Status: No, score=-6.826 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvzGeYKxCFRY for ; Sun, 6 Mar 2011 16:43:59 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 3E4DD28C0CF for ; Sun, 6 Mar 2011 16:43:58 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p270j7Ew029338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 6 Mar 2011 18:45:10 -0600 (CST) 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 p270j7ex012225 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 7 Mar 2011 06:15:07 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Mon, 7 Mar 2011 06:15:06 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Mon, 7 Mar 2011 06:15:23 +0530 Thread-Topic: A Generic Mechanism to solve Inter-Session Replay Attacks Thread-Index: AcvcYPGWaItCj65sR22n/VTqiQ7sbQ== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCC81D02@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [karp] A Generic Mechanism to solve Inter-Session Replay Attacks X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 00:44:00 -0000 Hi, One of the requirements listed in the KARP threat-reqs document is to work = on a mechanism that solves inter-session replay attacks in the routing and = the signaling protocols. Sam, Dacheng and I have written a small draft that= describes how this can be done. URL for the draft: http://www.ietf.org/id/draft-bhz-karp-inter-session-replay-00.txt Would be great to hear some feedback from the WG. Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From Internet-Drafts@ietf.org Mon Mar 7 11:15:04 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914FD3A680E; Mon, 7 Mar 2011 11:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnO-r1jPvoqN; Mon, 7 Mar 2011 11:15:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3053A67F9; Mon, 7 Mar 2011 11:15:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110307191503.10814.1693.idtracker@localhost> Date: Mon, 07 Mar 2011 11:15:03 -0800 Cc: karp@ietf.org Subject: [karp] I-D ACTION:draft-ietf-karp-ospf-analysis-00.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 19:15:04 -0000 --NextPart 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 OSPF Security According to KARP Design Guide Author(s) : S. Hartman, et al Filename : draft-ietf-karp-ospf-analysis-00.txt Pages : 15 Date : 2011-03-07 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-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-karp-ospf-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-07111300.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 7 18:00:10 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C5528C12C; Mon, 7 Mar 2011 18:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nmcPa+QyxdS; Mon, 7 Mar 2011 18:00:08 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3869C28C151; Mon, 7 Mar 2011 18:00:04 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110308020004.17578.1000.idtracker@localhost> Date: Mon, 07 Mar 2011 18:00:04 -0800 Cc: karp@ietf.org Subject: [karp] I-D ACTION:draft-ietf-karp-design-guide-02.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 02:00:10 -0000 --NextPart 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 : Keying and Authentication for Routing Protocols (KARP) Design Guidelines Author(s) : G. Lebovitz, et al Filename : draft-ietf-karp-design-guide-02.txt Pages : 28 Date : 2011-03-07 In the March of 2006 the IAB held a workshop on the topic of "Unwanted Internet Traffic". The report from that workshop is documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for [t]ightening the security of the core routing infrastructure." Four main steps were identified for improving the security of the routing infrastructure. One of those steps was "securing the routing protocols' packets on the wire." One mechanism for securing routing protocol packets on the wire is the use of per-packet cryptographic message authentication, providing both peer authentication and message integrity. Many different routing protocols exist and they employ a range of different transport subsystems. Therefore there must necessarily be various methods defined for applying cryptographic authentication to these varying protocols. Many routing protocols already have some method for accomplishing cryptographic message authentication. However, in many cases the existing methods are dated, vulnerable to attack, and/or employ cryptographic algorithms that have been deprecated. This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. The overall roadmap reflects the input of both the security area and routing area in order to form a jointly agreed upon and prioritized work list for the effort. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-design-guide-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-karp-design-guide-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-07175456.I-D@ietf.org> --NextPart-- From mahesh@cisco.com Mon Mar 7 18:17:15 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D8B3A68D6 for ; Mon, 7 Mar 2011 18:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.129 X-Spam-Level: X-Spam-Status: No, score=-8.129 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xZcqhNb9AsH for ; Mon, 7 Mar 2011 18:17:14 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 136AD3A68D0 for ; Mon, 7 Mar 2011 18:17:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mahesh@cisco.com; l=16234; q=dns/txt; s=iport; t=1299550708; x=1300760308; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=/sd+OHt4LApfCe38ma9T550wgYbaOnZtf/c0fmPyt74=; b=bOx4GKILhZbthS2XQ3SRb7nklgcPKKxs1OuZFJ/brnu1PsKpZyvDM8uD GdhXRrephVfnlngs3cufbl0YP1lHSTbo4bMyNh/mOoBOUBTBPQEulXtPI /aEoQoKafbvR9OWhQk1fxPYcXiL9yg0X/uwQg3drDXUQzoqWoJ5VLtsnq Y=; X-Files: spacer.gif, footerHead.gif, footer.gif : 55, 68, 347 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFALYgdU2rR7H+/2dsb2JhbACCT5wFAYMjhF90og2cLgKDFoJKBIUdhxU X-IronPort-AV: E=Sophos;i="4.62,281,1297036800"; d="gif'147?scan'147,208,217,147";a="412474493" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 08 Mar 2011 02:18:28 +0000 Received: from sjc-vpnasa-750.cisco.com (sjc-vpnasa-750.cisco.com [10.21.106.241]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p282ISoT020698 for ; Tue, 8 Mar 2011 02:18:28 GMT Message-ID: <4D759259.3040906@cisco.com> Date: Mon, 07 Mar 2011 18:20:09 -0800 From: Mahesh Jethanandani User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: karp@ietf.org References: <20110308020004.17578.1000.idtracker@localhost> In-Reply-To: <20110308020004.17578.1000.idtracker@localhost> Content-Type: multipart/alternative; boundary="------------040001030400060708040409" Subject: Re: [karp] I-D ACTION:draft-ietf-karp-design-guide-02.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 02:17:15 -0000 This is a multi-part message in MIME format. --------------040001030400060708040409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I suggested this nit in the draft and I do not see that it has been updated in this version of the draft. --------------------------------------------------------------------------- A nit. The draft says: > BGP [RFC4271 ] and MSDP [RFC3618 ] are transmitted > over TCP, while LDP [RFC5036 ] uses UDP. and > However, this cannot be used for LDP as LDP runs over UDP. While it is true that the hello discovery process for LDP runs over UDP, the actual LDP protocol runs over TCP. On 3/7/11 6:00 PM, 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 : Keying and Authentication for Routing Protocols (KARP) > Design Guidelines > Author(s) : G. Lebovitz, et al > Filename : draft-ietf-karp-design-guide-02.txt > Pages : 28 > Date : 2011-03-07 > > In the March of 2006 the IAB held a workshop on the topic of > "Unwanted Internet Traffic". The report from that workshop is > documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls > for [t]ightening the security of the core routing > infrastructure." Four main steps were identified for improving > the security of the routing infrastructure. One of those steps > was "securing the routing protocols' packets on the wire." One > mechanism for securing routing protocol packets on the wire is > the use of per-packet cryptographic message authentication, > providing both peer authentication and message integrity. Many > different routing protocols exist and they employ a range of > different transport subsystems. Therefore there must > necessarily be various methods defined for applying > cryptographic authentication to these varying protocols. Many > routing protocols already have some method for accomplishing > cryptographic message authentication. However, in many cases > the existing methods are dated, vulnerable to attack, and/or > employ cryptographic algorithms that have been deprecated. > This document is one of a series concerned with defining a > roadmap of protocol specification work for the use of modern > cryptographic mechanisms and algorithms for message > authentication in routing protocols. In particular, it defines > the framework for a key management protocol that may be used to > create and manage session keys for message authentication and > integrity. The overall roadmap reflects the input of both the > security area and routing area in order to form a jointly > agreed upon and prioritized work list for the effort. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-karp-design-guide-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp -- *Mahesh Jethanandani* *Technical Leader* **ERBU* * mahesh@cisco.com Phone :*+1 408 527-8230* Fax :*+1 408 853-0762* ** 170 West Tasman Drive San Jose, CA 95070 United States www.cisco.com This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. --------------040001030400060708040409 Content-Type: multipart/related; boundary="------------060301050902000909080408" --------------060301050902000909080408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I suggested this nit in the draft and I do not see that it has been updated in this version of the draft.

---------------------------------------------------------------------------

A nit.

The draft says:

BGP [RFC4271] and MSDP [RFC3618] are transmitted
         over TCP, while LDP [RFC5036] uses UDP.
and

However, this cannot be used for LDP as LDP runs over UDP.
While it is true that the hello discovery process for LDP runs over UDP, the actual LDP protocol runs over TCP.



On 3/7/11 6:00 PM, 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         : Keying and Authentication for Routing Protocols (KARP) 
Design Guidelines
    Author(s)     : G. Lebovitz, et al
    Filename      : draft-ietf-karp-design-guide-02.txt
    Pages         : 28
    Date          : 2011-03-07
    
In the March of 2006 the IAB held a workshop on the topic of 
      "Unwanted Internet Traffic".  The report from that workshop is 
      documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls 
      for [t]ightening the security of the core routing 
      infrastructure."  Four main steps were identified for improving 
      the security of the routing infrastructure.  One of those steps 
      was "securing the routing protocols' packets on the wire."  One 
      mechanism for securing routing protocol packets on the wire is 
      the use of per-packet cryptographic message authentication, 
      providing both peer authentication and message integrity.  Many 
      different routing protocols exist and they employ a range of 
      different transport subsystems.  Therefore there must 
      necessarily be various methods defined for applying 
      cryptographic authentication to these varying protocols.  Many 
      routing protocols already have some method for accomplishing 
      cryptographic message authentication.  However, in many cases 
      the existing methods are dated, vulnerable to attack, and/or 
      employ cryptographic algorithms that have been deprecated.  
      This document is one of a series concerned with defining a 
      roadmap of protocol specification work for the use of modern 
      cryptographic mechanisms and algorithms for message 
      authentication in routing protocols.  In particular, it defines 
      the framework for a key management protocol that may be used to 
      create and manage session keys for message authentication and 
      integrity.  The overall roadmap reflects the input of both the 
      security area and routing area in order to form a jointly 
      agreed upon and prioritized work list for the effort. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-karp-design-guide-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp

--

Mahesh Jethanandani
Technical Leader
ERBU

mahesh@cisco.com
Phone :+1 408 527-8230
Fax :+1 408 853-0762


170 West Tasman Drive
San Jose, CA 95070
United States
www.cisco.com

  
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.


--------------060301050902000909080408 Content-Type: image/gif; name="spacer.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="spacer.gif" R0lGODlhCgAKAJEAAAAAAP///////wAAACH5BAEAAAIALAAAAAAKAAoAAAIIlI+py+0PYysA Ow== --------------060301050902000909080408 Content-Type: image/gif; name="footerHead.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="footerHead.gif" R0lGODlhHwIBAJEAAAAAAP///9bY2v///yH5BAEAAAMALAAAAAAfAgEAAAIVlI+py+0Po5y0 2ouz3rz7D4biSE4FADs= --------------060301050902000909080408 Content-Type: image/gif; name="footer.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="footer.gif" R0lGODlhHwIRAMQAAAAAAP////f3+PX19vHx8u7u7+jp6+Tl59/g4tze4Nvd39ja3NfZ29bY 2vHy8+3u7+vs7eTl5ufp6uTm597g4dze3/j5+fHy8v7+/v39/fv7+/n5+f///wAAAAAAAAAA ACH5BAEAABwALAAAAAAfAhEAAAXY4JIFZGmeaKqubOu+cCzPdG3feK7vfO//wKCwlVkkNsOk cslsOp/QqHRKFW4SE0J1y+16v+CweJwkZCfktHrNbrvf7yymMoDb7/i8fp8fKDABFweAfIWG h4iJijIYBxclBhIai5SVlpeYXhoSBicQDA+ZoqOkpaYuBQwQKRsIERcCp7KztLV2Ag4RCBYs DgcUDcHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3twUEQ625OXm5+jp6uvs7e7v8PHy 8/T19vf4+fr7/P3+/wADChxIUEYIADs= --------------060301050902000909080408-- --------------040001030400060708040409-- From manav.bhatia@alcatel-lucent.com Mon Mar 7 18:24:53 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568603A68B6 for ; Mon, 7 Mar 2011 18:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.362 X-Spam-Level: X-Spam-Status: No, score=-5.362 tagged_above=-999 required=5 tests=[AWL=-1.727, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iGQ9Zpw0jOM for ; Mon, 7 Mar 2011 18:24:51 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 60D623A680B for ; Mon, 7 Mar 2011 18:24:51 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p282Q0Qp026322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Mar 2011 20:26:03 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p282Q0Pe018385 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Mar 2011 07:56:00 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 8 Mar 2011 07:55:59 +0530 From: "Bhatia, Manav (Manav)" To: Mahesh Jethanandani , "karp@ietf.org" Date: Tue, 8 Mar 2011 07:55:59 +0530 Thread-Topic: [karp] I-D ACTION:draft-ietf-karp-design-guide-02.txt Thread-Index: AcvdNyISeY/PvTFAQTqscW1jSkLKSwAAOCcQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCD56C59@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20110308020004.17578.1000.idtracker@localhost> <4D759259.3040906@cisco.com> In-Reply-To: <4D759259.3040906@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_7C362EEF9C7896468B36C9B79200D8350CFCD56C59INBANSXCHMBSA_"; type="multipart/alternative" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [karp] I-D ACTION:draft-ietf-karp-design-guide-02.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 02:24:53 -0000 --_006_7C362EEF9C7896468B36C9B79200D8350CFCD56C59INBANSXCHMBSA_ Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350CFCD56C59INBANSXCHMBSA_" --_000_7C362EEF9C7896468B36C9B79200D8350CFCD56C59INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mahesh, I am sorry, i missed this. Will update this in the next version. The draft = was only revised to prevent it from expiring. Cheers, Manav ________________________________ From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Mah= esh Jethanandani Sent: Tuesday, March 08, 2011 7.50 AM To: karp@ietf.org Subject: Re: [karp] I-D ACTION:draft-ietf-karp-design-guide-02.txt I suggested this nit in the draft and I do not see that it has been updated= in this version of the draft. --------------------------------------------------------------------------- A nit. The draft says: BGP [RFC4271] and MSDP [RFC3618] are transmitted over TCP, while LDP [RFC5036] = uses UDP. and However, this cannot be used for LDP as LDP runs over UDP. While it is true that the hello discovery process for LDP runs over UDP, th= e actual LDP protocol runs over TCP. On 3/7/11 6:00 PM, Internet-Drafts@ietf.org wrote: 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 Prot= ocols Working Group of the IETF. Title : Keying and Authentication for Routing Protocols (KARP) Design Guidelines Author(s) : G. Lebovitz, et al Filename : draft-ietf-karp-design-guide-02.txt Pages : 28 Date : 2011-03-07 In the March of 2006 the IAB held a workshop on the topic of "Unwanted Internet Traffic". The report from that workshop is documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for [t]ightening the security of the core routing infrastructure." Four main steps were identified for improving the security of the routing infrastructure. One of those steps was "securing the routing protocols' packets on the wire." One mechanism for securing routing protocol packets on the wire is the use of per-packet cryptographic message authentication, providing both peer authentication and message integrity. Many different routing protocols exist and they employ a range of different transport subsystems. Therefore there must necessarily be various methods defined for applying cryptographic authentication to these varying protocols. Many routing protocols already have some method for accomplishing cryptographic message authentication. However, in many cases the existing methods are dated, vulnerable to attack, and/or employ cryptographic algorithms that have been deprecated. This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. The overall roadmap reflects the input of both the security area and routing area in order to form a jointly agreed upon and prioritized work list for the effort. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-design-guide-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp -- [cid:406542402@08032011-1CFB] Mahesh Jethanandani Technical Leader ERBU mahesh@cisco.com Phone :+1 408 527-8230 Fax :+1 408 853-0762 170 West Tasman Drive San Jose, CA 95070 United States www.cisco.com This e-mail may contain confidential and privileged material for the sole u= se of the intended recipient. Any review, use, distribution or disclosure b= y others is strictly prohibited. If you are not the intended recipient (or = authorized to receive for the recipient), please contact the sender by repl= y e-mail and delete all copies of this message. [cid:406542402@08032011-1D09] --_000_7C362EEF9C7896468B36C9B79200D8350CFCD56C59INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Mahesh,

I am sorry, i=20 missed this. Will update this in the next version. The draft was only revis= ed to=20 prevent it from expiring.
 
Cheers, Manav

From: karp-bounces@ietf.org=20 [mailto:karp-bounces@ietf.org] On Behalf Of Mahesh=20 Jethanandani
Sent: Tuesday, March 08, 2011 7.50 AM
To:=20 karp@ietf.org
Subject: Re: [karp] I-D=20 ACTION:draft-ietf-karp-design-guide-02.txt

I suggested this nit in the draft and I do not see that it has= been=20 updated in this version of the=20 draft.

-----------------------------------------------------------= ----------------

A=20 nit.

The draft says:

BGP [RFC4271] and MSDP [RFC3618] are transmitted
         over TCP, while LDP [RFC5036] uses UDP.
<= /BLOCKQUOTE>and

However, this cannot be used for LDP as LDP runs over UDP.
While=20 it is true that the hello discovery process for LDP runs over UDP, the ac= tual=20 LDP protocol runs over TCP.



On 3/7/11 6:00 PM, Internet-Drafts@ietf.org wro= te:=20 
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 Prot=
ocols Working Group of the IETF.

    Title         : Keying and Authentication for Routing Protocols (KARP)=
=20
Design Guidelines
    Author(s)     : G. Lebovitz, et al
    Filename      : draft-ietf-karp-design-guide-02.txt
    Pages         : 28
    Date          : 2011-03-07
   =20
In the March of 2006 the IAB held a workshop on the topic of=20
      "Unwanted Internet Traffic".  The report from that workshop is=20
      documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls=20
      for [t]ightening the security of the core routing=20
      infrastructure."  Four main steps were identified for improving=20
      the security of the routing infrastructure.  One of those steps=20
      was "securing the routing protocols' packets on the wire."  One=20
      mechanism for securing routing protocol packets on the wire is=20
      the use of per-packet cryptographic message authentication,=20
      providing both peer authentication and message integrity.  Many=20
      different routing protocols exist and they employ a range of=20
      different transport subsystems.  Therefore there must=20
      necessarily be various methods defined for applying=20
      cryptographic authentication to these varying protocols.  Many=20
      routing protocols already have some method for accomplishing=20
      cryptographic message authentication.  However, in many cases=20
      the existing methods are dated, vulnerable to attack, and/or=20
      employ cryptographic algorithms that have been deprecated. =20
      This document is one of a series concerned with defining a=20
      roadmap of protocol specification work for the use of modern=20
      cryptographic mechanisms and algorithms for message=20
      authentication in routing protocols.  In particular, it defines=20
      the framework for a key management protocol that may be used to=20
      create and manage session keys for message authentication and=20
      integrity.  The overall roadmap reflects the input of both the=20
      security area and routing area in order to form a jointly=20
      agreed upon and prioritized work list for the effort.=20

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/=
draft-ietf-karp-design-guide-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


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

--
Mahesh=20 Jethanandani
Technical=20 Leader
ERBU
=
mahesh@cisco.com
Phon= e=20 :+1 408 527-8230
Fax :+1 408=20 853-0762
17= 0=20 West Tasman Drive
San Jose, CA 95070
United States
<= A=20 style=3D"COLOR: rgb(102,102,102)"=20 href=3D"http://www.cisco.com">www.cisco.com

  
This=20 e-mail may contain confidential and privileged material for t= he=20 sole use of the intended recipient. Any review, use, distribu= tion=20 or disclosure by others is strictly prohibited. If you are no= t the=20 intended recipient (or authorized to receive for the recipien= t),=20 please contact the sender by reply e-mail and delete all copi= es of=20 this message.

--_000_7C362EEF9C7896468B36C9B79200D8350CFCD56C59INBANSXCHMBSA_-- --_006_7C362EEF9C7896468B36C9B79200D8350CFCD56C59INBANSXCHMBSA_ Content-Type: image/gif; name="spacer.gif" Content-Description: spacer.gif Content-Disposition: inline; filename="spacer.gif"; size=55; creation-date="Tue, 08 Mar 2011 07:55:57 GMT"; modification-date="Tue, 08 Mar 2011 07:55:57 GMT" Content-ID: <406542402@08032011-1CFB> Content-Transfer-Encoding: base64 R0lGODlhCgAKAJEAAAAAAP///////wAAACH5BAEAAAIALAAAAAAKAAoAAAIIlI+py+0PYysAOw== --_006_7C362EEF9C7896468B36C9B79200D8350CFCD56C59INBANSXCHMBSA_ Content-Type: image/gif; name="footerHead.gif" Content-Description: footerHead.gif Content-Disposition: inline; filename="footerHead.gif"; size=68; creation-date="Tue, 08 Mar 2011 07:55:57 GMT"; modification-date="Tue, 08 Mar 2011 07:55:57 GMT" Content-ID: <406542402@08032011-1D02> Content-Transfer-Encoding: base64 R0lGODlhHwIBAJEAAAAAAP///9bY2v///yH5BAEAAAMALAAAAAAfAgEAAAIVlI+py+0Po5y02ouz 3rz7D4biSE4FADs= --_006_7C362EEF9C7896468B36C9B79200D8350CFCD56C59INBANSXCHMBSA_ Content-Type: image/gif; name="footer.gif" Content-Description: footer.gif Content-Disposition: inline; filename="footer.gif"; size=347; creation-date="Tue, 08 Mar 2011 07:55:58 GMT"; modification-date="Tue, 08 Mar 2011 07:55:58 GMT" Content-ID: <406542402@08032011-1D09> Content-Transfer-Encoding: base64 R0lGODlhHwIRAMQAAAAAAP////f3+PX19vHx8u7u7+jp6+Tl59/g4tze4Nvd39ja3NfZ29bY2vHy 8+3u7+vs7eTl5ufp6uTm597g4dze3/j5+fHy8v7+/v39/fv7+/n5+f///wAAAAAAAAAAACH5BAEA ABwALAAAAAAfAhEAAAXY4JIFZGmeaKqubOu+cCzPdG3feK7vfO//wKCwlVkkNsOkcslsOp/QqHRK FW4SE0J1y+16v+CweJwkZCfktHrNbrvf7yymMoDb7/i8fp8fKDABFweAfIWGh4iJijIYBxclBhIa i5SVlpeYXhoSBicQDA+ZoqOkpaYuBQwQKRsIERcCp7KztLV2Ag4RCBYsDgcUDcHCw8TFxsfIycrL zM3Oz9DR0tPU1dbX2Nna29zd3twUEQ625OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wADChxI UEYIADs= --_006_7C362EEF9C7896468B36C9B79200D8350CFCD56C59INBANSXCHMBSA_-- From bew@cisco.com Mon Mar 14 09:47:58 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95DD93A6D0D for ; Mon, 14 Mar 2011 09:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhWwDHGW1c-C for ; Mon, 14 Mar 2011 09:47:57 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8048D3A6E46 for ; Mon, 14 Mar 2011 09:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=297; q=dns/txt; s=iport; t=1300121335; x=1301330935; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=FZjrpJT6s16z7AfbtaA5jAY3jlbMK94+SkUbYck3hyc=; b=WEH2FODPDjizH/T8t7M4Kw8BFw5nnAatkdpENpiQZCzz/iLHKq5A7/gS x21C52WVFE3rcQkBMLV1LdxqrdV6WGsJ2ZB31pWFi84ttM/VUxqsmM5al RzqKB9s/mL4haH3amAlk3lx49YhOXkx8Otz0UzKt7XZp6DnUrEpnBXmGo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQHAOXjfU2tJV2Y/2dsb2JhbACZA40Gd6QanAuFYgSFK4cn X-IronPort-AV: E=Sophos;i="4.62,316,1297036800"; d="scan'208";a="277799645" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 14 Mar 2011 16:48:55 +0000 Received: from dhcp-128-107-147-45.cisco.com (dhcp-128-107-147-45.cisco.com [128.107.147.45]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2EGmsHE011949 for ; Mon, 14 Mar 2011 16:48:54 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 09:48:53 -0700 Message-Id: <2BB13147-2CF4-495E-BAA9-17C229464102@cisco.com> To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [karp] Call for IETF 80 agenda items X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 16:47:58 -0000 Greetings, The KARP WG will be meeting Friday morning in Prague. We have several WG = documents to discuss, as well as design team results for OSPF and = BGP/LDP/MSDP. If you have an additional topic for the meeting please = email the chairs (karp-chairs@tools.ietf.org). Thanks, Brian From liang.xiaoping@zte.com.cn Mon Mar 14 19:43:16 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F02A3A6BBA; Mon, 14 Mar 2011 19:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi9ivuXSlgf5; Mon, 14 Mar 2011 19:43:15 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 523983A6973; Mon, 14 Mar 2011 19:43:12 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 50832175658078; Tue, 15 Mar 2011 10:43:30 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 98052.3055181326; Tue, 15 Mar 2011 10:34:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p2F2iRbP018825; Tue, 15 Mar 2011 10:44:27 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: <4D6C2164.8020308@joelhalpern.com> To: "Joel M. Halpern" MIME-Version: 1.0 X-KeepSent: 7DA96CA5:6A6C2681-48257854:000F084D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Tue, 15 Mar 2011 10:44:32 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-15 10:44:27, Serialize complete at 2011-03-15 10:44:27 Content-Type: multipart/alternative; boundary="=_alternative 000F1B6148257854_=" X-MAIL: mse01.zte.com.cn p2F2iRbP018825 Cc: karp-bounces@ietf.org, "karp@ietf.org" Subject: Re: [karp] WG Last Call: draft-ietf-karp-design-guide-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 02:43:16 -0000 This is a multipart message in MIME format. --=_alternative 000F1B6148257854_= Content-Type: text/plain; charset="US-ASCII" Support! +1 ^_^ This document: http://datatracker.ietf.org/doc/draft-ietf-karp-design-guide/ Keying and Authentication for Routing Protocols (KARP) Design Guidelines is a working group document. It is a charter deliverable. There have been no comments or discussion recently. The chairs are therefore asking for a WG last call, with the view of sending this to our AD for publication as an Informational RFC Yours, Joel M. Halpern _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000F1B6148257854_= Content-Type: text/html; charset="US-ASCII"
Support! +1  ^_^


This document:
http://datatracker.ietf.org/doc/draft-ietf-karp-design-guide/
Keying and Authentication for Routing Protocols (KARP) Design Guidelines
is a working group document.  It is a charter deliverable.  There have
been no comments or discussion recently.

The chairs are therefore asking for a WG last call, with the view of
sending this to our AD for publication as an Informational RFC

Yours,
Joel M. Halpern
_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000F1B6148257854_=-- From bill@cse.concordia.ca Mon Mar 14 19:43:51 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B563A6B88 for ; Mon, 14 Mar 2011 19:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3smHPkAQuyn for ; Mon, 14 Mar 2011 19:43:50 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.94]) by core3.amsl.com (Postfix) with ESMTP id 870F73A6A80 for ; Mon, 14 Mar 2011 19:43:50 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id p2F2jE8a024614 for ; Mon, 14 Mar 2011 22:45:14 -0400 Message-ID: <4D7ED2B9.7060203@cse.concordia.ca> Date: Mon, 14 Mar 2011 22:45:13 -0400 From: Bill Atwood Organization: Concordia University, Department of Computer Science and Software Engineering User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: karp@ietf.org References: <4D6C2164.8020308@joelhalpern.com> In-Reply-To: <4D6C2164.8020308@joelhalpern.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2011/03/14 22:45:14 EDT Subject: Re: [karp] WG Last Call: draft-ietf-karp-design-guide-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 02:43:51 -0000 I support this. jwa On 2/28/2011 5:27 PM, Joel M. Halpern wrote: > This document: > http://datatracker.ietf.org/doc/draft-ietf-karp-design-guide/ > Keying and Authentication for Routing Protocols (KARP) Design Guidelines > is a working group document. It is a charter deliverable. There have > been no comments or discussion recently. > > The chairs are therefore asking for a WG last call, with the view of > sending this to our AD for publication as an Informational RFC > > Yours, > Joel M. Halpern > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From liang.xiaoping@zte.com.cn Mon Mar 14 19:44:19 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD763A6A80; Mon, 14 Mar 2011 19:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.724 X-Spam-Level: X-Spam-Status: No, score=-101.724 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Os19WAsnBGSK; Mon, 14 Mar 2011 19:44:19 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 6FC703A6973; Mon, 14 Mar 2011 19:44:18 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 50832175658078; Tue, 15 Mar 2011 10:44:57 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 98052.3055181326; Tue, 15 Mar 2011 10:35:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p2F2jZx5098545; Tue, 15 Mar 2011 10:45:35 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: <4D6C2254.5000602@joelhalpern.com> To: "Joel M. Halpern" MIME-Version: 1.0 X-KeepSent: 4A5F0940:63CB8045-48257854:000F2144; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Tue, 15 Mar 2011 10:45:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-15 10:45:35, Serialize complete at 2011-03-15 10:45:35 Content-Type: multipart/alternative; boundary="=_alternative 000F35F548257854_=" X-MAIL: mse02.zte.com.cn p2F2jZx5098545 Cc: karp-bounces@ietf.org, "karp@ietf.org" Subject: Re: [karp] WG LC: draft-ietf-karp-threats-reqs-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 02:44:20 -0000 This is a multipart message in MIME format. --=_alternative 000F35F548257854_= Content-Type: text/plain; charset="US-ASCII" Support! +1 ^_^ This document: http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports is a working group document. It is a charter deliverable. There have been no comments or discussion recently. The chairs are therefore asking for a WG last call, with the view of sending this to our AD for publication as an Proposed Standard RFC. This Last Call will last 2 weeks, ending at the end of the day March 14th. Yours, Joel (and Brian) PS: which is how I should have signed the last one. Sorry, bad habits. _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000F35F548257854_= Content-Type: text/html; charset="US-ASCII"
Support! +1 ^_^
 


This document:
http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/
The Threat Analysis and Requirements for Cryptographic Authentication of
Routing Protocols' Transports
is a working group document.  It is a charter deliverable.  There have
been no comments or discussion recently.

The chairs are therefore asking for a WG last call, with the view of
sending this to our AD for publication as an Proposed Standard RFC.
This Last Call will last 2 weeks, ending at the end of the day March 14th.

Yours,
Joel (and Brian)

PS: which is how I should have signed the last one.  Sorry, bad habits.
_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000F35F548257854_=-- From bill@cse.concordia.ca Mon Mar 14 19:44:24 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756383A6B88 for ; Mon, 14 Mar 2011 19:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGDo9e8Kw3dU for ; Mon, 14 Mar 2011 19:44:23 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.94]) by core3.amsl.com (Postfix) with ESMTP id 9445C3A6AD4 for ; Mon, 14 Mar 2011 19:44:23 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id p2F2jlTr024682 for ; Mon, 14 Mar 2011 22:45:47 -0400 Message-ID: <4D7ED2DA.5080002@cse.concordia.ca> Date: Mon, 14 Mar 2011 22:45:46 -0400 From: Bill Atwood Organization: Concordia University, Department of Computer Science and Software Engineering User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: karp@ietf.org References: <4D6C2254.5000602@joelhalpern.com> In-Reply-To: <4D6C2254.5000602@joelhalpern.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2011/03/14 22:45:47 EDT Subject: Re: [karp] WG LC: draft-ietf-karp-threats-reqs-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 02:44:24 -0000 I support this. jwa On 2/28/2011 5:31 PM, Joel M. Halpern wrote: > This document: > http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ > The Threat Analysis and Requirements for Cryptographic Authentication > of Routing Protocols' Transports > is a working group document. It is a charter deliverable. There have > been no comments or discussion recently. > > The chairs are therefore asking for a WG last call, with the view of > sending this to our AD for publication as an Proposed Standard RFC. > This Last Call will last 2 weeks, ending at the end of the day March > 14th. > > Yours, > Joel (and Brian) > > PS: which is how I should have signed the last one. Sorry, bad habits. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From liang.xiaoping@zte.com.cn Mon Mar 14 19:50:00 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724403A6AD4; Mon, 14 Mar 2011 19:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.781 X-Spam-Level: X-Spam-Status: No, score=-101.781 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwIdP36tgHtf; Mon, 14 Mar 2011 19:49:59 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id D017D3A6973; Mon, 14 Mar 2011 19:49:58 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 50832175658078; Tue, 15 Mar 2011 10:50:37 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 84746.3055181326; Tue, 15 Mar 2011 10:51:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p2F2pGY5005833; Tue, 15 Mar 2011 10:51:16 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: <4D6C23FD.1020106@joelhalpern.com> To: "Joel M. Halpern" MIME-Version: 1.0 X-KeepSent: 8537A333:35181FE2-48257854:000FB12D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Tue, 15 Mar 2011 10:51:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-15 10:51:17, Serialize complete at 2011-03-15 10:51:17 Content-Type: multipart/alternative; boundary="=_alternative 000FBB5C48257854_=" X-MAIL: mse02.zte.com.cn p2F2pGY5005833 Cc: karp-bounces@ietf.org, "karp@ietf.org" Subject: Re: [karp] WG Adoption: draft-hartman-karp-ops-model-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 02:50:00 -0000 This is a multipart message in MIME format. --=_alternative 000FBB5C48257854_= Content-Type: text/plain; charset="US-ASCII" Support! This document: http://datatracker.ietf.org/doc/draft-hartman-karp-ops-model/ Operations Model for Router Keying has been placed before WG to address the charter deliverable: Submit a document describing best practices for creating and using protocol message authentication integrity keys as a BCP. There was some discussion earlier, but not a great deal. based on what there was, and the content of the document, the chairs would like to adopt this document as a Working Group document, with the intention of addressing the chartered work item. We are requesting comments from the WG on taking this as the starting point for this WG work. We would like to hear within the next two weeks, by the end of the day March 14. Yours, Joel (and Brian) _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000FBB5C48257854_= Content-Type: text/html; charset="US-ASCII"
Support!  
 


This document:
http://datatracker.ietf.org/doc/draft-hartman-karp-ops-model/
Operations Model for Router Keying

has been placed before WG to address the charter deliverable:
Submit a document describing best practices for creating and using
protocol message authentication integrity keys as a BCP.

There was some discussion earlier, but not a great deal.
based on what there was, and the content of the document, the chairs
would like to adopt this document as a Working Group document, with the
intention of addressing the chartered work item.

We are requesting comments from the WG on taking this as the starting
point for this WG work.
We would like to hear within the next two weeks, by the end of the day
March 14.

Yours,
Joel (and Brian)
_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000FBB5C48257854_=-- From liang.xiaoping@zte.com.cn Mon Mar 14 20:45:07 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524B73A6AB4 for ; Mon, 14 Mar 2011 20:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64gGCgaDJLyU for ; Mon, 14 Mar 2011 20:45:05 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id A3F733A6A11 for ; Mon, 14 Mar 2011 20:45:04 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510536813104; Tue, 15 Mar 2011 11:44:07 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 84746.536813104; Tue, 15 Mar 2011 11:33:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p2F3XNHQ012500 for ; Tue, 15 Mar 2011 11:33:23 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) To: karp@ietf.org MIME-Version: 1.0 X-KeepSent: 8363B64E:180F56EA-48257854:000FF259; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Tue, 15 Mar 2011 11:33:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-15 11:33:23, Serialize complete at 2011-03-15 11:33:23 Content-Type: multipart/alternative; boundary="=_alternative 0013966048257854_=" X-MAIL: mse02.zte.com.cn p2F3XNHQ012500 Subject: [karp] Welcome to discussion and comments on draft-liang-karp-negotiation-kmp-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 03:45:07 -0000 This is a multipart message in MIME format. --=_alternative 0013966048257854_= Content-Type: text/plain; charset="US-ASCII" Hi all, Here is a new draft on negotiation in KMPs, which is inspired by the discussion on negotiation initiated by Sam. Discussion and comments are welcome! http://www.ietf.org/id/draft-liang-karp-negotiation-kmp-00.txt Negotiation is one prominent capability of keying managament protocols (KMPs), especially automated KMPs for Routing Protocols. This document discusses negotiation in KMPs, which includes the reasons for negotiation in KMPs, concerns and possible solutions when using negotiation, and several types of negotiation in KMPs. Best regards, Ellen (Xiaoping Liang) -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0013966048257854_= Content-Type: text/html; charset="US-ASCII"
Hi all,

Here is a new draft on negotiation in KMPs, which is inspired by the discussion on negotiation initiated by Sam. Discussion and comments are welcome!

http://www.ietf.org/id/draft-liang-karp-negotiation-kmp-00.txt

Negotiation is one prominent capability of keying managament protocols (KMPs), especially automated KMPs for Routing Protocols. This document discusses negotiation in KMPs, which includes the reasons for negotiation in KMPs, concerns and possible solutions when using negotiation, and several types of negotiation in KMPs.

Best regards,
Ellen (Xiaoping Liang)
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0013966048257854_=-- From vnktshsriram@gmail.com Mon Mar 14 21:22:55 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7D83A697E for ; Mon, 14 Mar 2011 21:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qedgLh2wVRxs for ; Mon, 14 Mar 2011 21:22:54 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 96A1D3A6950 for ; Mon, 14 Mar 2011 21:22:52 -0700 (PDT) Received: by vxg33 with SMTP id 33so258552vxg.31 for ; Mon, 14 Mar 2011 21:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yncQcB99AROC56bNByxodJRaOYVMAL6DH9rmGAA14us=; b=djBRBLwIQRBBy035oBu3oOUgIqLgpAcrdUQXcmCL7AHmfKHP/VqmB96Iess7TpnLaI 76CNiwy46PUprbz8OGUs2fayO/x8mVfD+DCvE+IgXQV43VZgR8i3GI0LDXTH7qMwREi7 x7WA6t9D2eIdyAH6VzxVr2X4NxcNC5BfFnWk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=or12ljIJ1XtjNuvJfX8mlRt2WEEEBITfSLj2jYB1BrvH2FCmyDRIYxFeFFhXfE37HL vfLIDnz9W67q1idSOffcp88glUjbTS0YAju663Fy+gMGQM/dhm7G8sIMFAEQhZ68OmV3 RlS71LB+5CSfqAb0r6DOSKpOvTH4rbr8T9Fzk= MIME-Version: 1.0 Received: by 10.52.180.33 with SMTP id dl1mr544525vdc.304.1300163055748; Mon, 14 Mar 2011 21:24:15 -0700 (PDT) Received: by 10.52.93.2 with HTTP; Mon, 14 Mar 2011 21:24:15 -0700 (PDT) In-Reply-To: <4D7ED2DA.5080002@cse.concordia.ca> References: <4D6C2254.5000602@joelhalpern.com> <4D7ED2DA.5080002@cse.concordia.ca> Date: Tue, 15 Mar 2011 09:54:15 +0530 Message-ID: From: Venkatesh Sriram To: Bill Atwood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: karp@ietf.org Subject: Re: [karp] WG LC: draft-ietf-karp-threats-reqs-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 04:22:55 -0000 +1 On Tue, Mar 15, 2011 at 8:15 AM, Bill Atwood wrote: > I support this. > > =A0jwa > > On 2/28/2011 5:31 PM, Joel M. Halpern wrote: >> This document: >> http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ >> The Threat Analysis and Requirements for Cryptographic Authentication >> of Routing Protocols' Transports >> is a working group document. =A0It is a charter deliverable. =A0There ha= ve >> been no comments or discussion recently. >> >> The chairs are therefore asking for a WG last call, with the view of >> sending this to our AD for publication as an Proposed Standard RFC. >> This Last Call will last 2 weeks, ending at the end of the day March >> 14th. >> >> Yours, >> Joel (and Brian) >> >> PS: which is how I should have signed the last one. =A0Sorry, bad habits= . >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp > > -- > > Dr. J.W. Atwood, Eng. =A0 =A0 =A0 =A0 =A0 =A0 tel: =A0 +1 (514) 848-2424 = x3046 > Distinguished Professor Emeritus =A0fax: =A0 +1 (514) 848-2830 > Department of Computer Science > =A0 and Software Engineering > Concordia University EV 3.185 =A0 =A0 email: bill@cse.concordia.ca > 1455 de Maisonneuve Blvd. West =A0 =A0http: //users.encs.concordia.ca/~bi= ll > Montreal, Quebec Canada H3G 1M8 > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From vnktshsriram@gmail.com Mon Mar 14 21:23:14 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28213A69AD for ; Mon, 14 Mar 2011 21:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.986 X-Spam-Level: X-Spam-Status: No, score=-2.986 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZwvi6-dZaxR for ; Mon, 14 Mar 2011 21:23:13 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B16223A6950 for ; Mon, 14 Mar 2011 21:23:13 -0700 (PDT) Received: by vws12 with SMTP id 12so257293vws.31 for ; Mon, 14 Mar 2011 21:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yNykIRcBey+8TP/MMVm8wgz3hTg0/yE9bkXTcW7iCpI=; b=RqexfF0jLSH0zY8zT86FEPUP/jPaLs+/PJmlVhaYVgJWsCUcTWfYsTs1QFNQ2tyHN9 gcPWZiKOYMoNCjG0mORQa2ms95pv9V7zxBrXfjJwXbRBgXz4jdXgx9iHWMX8CX4SME0j /JrAxHaRDrCud9w18IJ1Hk7JImcJdjv5F63kA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gr2JPthp6HZUAgxlcMc2+xLhOsgU/P2KyBaBey/k+X2WRwTTc16tVrOkNsJxnuMccL qLxl1LbeeXo010ltkSQypO6Kvy/byqWflHapFbPphXSfY33n7DeO/zMV1ie9qK7Pml7Y nw7Ly1+ckr3L9RnQIr09cW+GUsTHI4m65jUJw= MIME-Version: 1.0 Received: by 10.52.0.5 with SMTP id 5mr2684840vda.120.1300163077856; Mon, 14 Mar 2011 21:24:37 -0700 (PDT) Received: by 10.52.93.2 with HTTP; Mon, 14 Mar 2011 21:24:37 -0700 (PDT) In-Reply-To: <4D7ED2B9.7060203@cse.concordia.ca> References: <4D6C2164.8020308@joelhalpern.com> <4D7ED2B9.7060203@cse.concordia.ca> Date: Tue, 15 Mar 2011 09:54:37 +0530 Message-ID: From: Venkatesh Sriram To: Bill Atwood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: karp@ietf.org Subject: Re: [karp] WG Last Call: draft-ietf-karp-design-guide-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 04:23:14 -0000 +1 On Tue, Mar 15, 2011 at 8:15 AM, Bill Atwood wrote: > I support this. > > =A0jwa > > On 2/28/2011 5:27 PM, Joel M. Halpern wrote: >> This document: >> http://datatracker.ietf.org/doc/draft-ietf-karp-design-guide/ >> Keying and Authentication for Routing Protocols (KARP) Design Guidelines >> is a working group document. =A0It is a charter deliverable. =A0There ha= ve >> been no comments or discussion recently. >> >> The chairs are therefore asking for a WG last call, with the view of >> sending this to our AD for publication as an Informational RFC >> >> Yours, >> Joel M. Halpern >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp > > -- > > Dr. J.W. Atwood, Eng. =A0 =A0 =A0 =A0 =A0 =A0 tel: =A0 +1 (514) 848-2424 = x3046 > Distinguished Professor Emeritus =A0fax: =A0 +1 (514) 848-2830 > Department of Computer Science > =A0 and Software Engineering > Concordia University EV 3.185 =A0 =A0 email: bill@cse.concordia.ca > 1455 de Maisonneuve Blvd. West =A0 =A0http: //users.encs.concordia.ca/~bi= ll > Montreal, Quebec Canada H3G 1M8 > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From bill@cse.concordia.ca Tue Mar 15 06:36:25 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624FD3A6D86 for ; Tue, 15 Mar 2011 06:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-ghUZlVYjys for ; Tue, 15 Mar 2011 06:36:24 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.94]) by core3.amsl.com (Postfix) with ESMTP id 15B913A6D14 for ; Tue, 15 Mar 2011 06:36:23 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id p2FDblpH024043 for ; Tue, 15 Mar 2011 09:37:48 -0400 Message-ID: <4D7F6BAC.9010705@cse.concordia.ca> Date: Tue, 15 Mar 2011 09:37:48 -0400 From: Bill Atwood Organization: Concordia University, Department of Computer Science and Software Engineering User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: karp@ietf.org References: <4D6C23FD.1020106@joelhalpern.com> In-Reply-To: <4D6C23FD.1020106@joelhalpern.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2011/03/15 09:37:48 EDT Subject: Re: [karp] WG Adoption: draft-hartman-karp-ops-model-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 13:36:25 -0000 I am in favor of adoption as a WG document. jwa On 2/28/2011 5:38 PM, Joel M. Halpern wrote: > This document: > http://datatracker.ietf.org/doc/draft-hartman-karp-ops-model/ > Operations Model for Router Keying > > has been placed before WG to address the charter deliverable: > Submit a document describing best practices for creating and using > protocol message authentication integrity keys as a BCP. > > There was some discussion earlier, but not a great deal. > based on what there was, and the content of the document, the chairs > would like to adopt this document as a Working Group document, with > the intention of addressing the chartered work item. > > We are requesting comments from the WG on taking this as the starting > point for this WG work. > We would like to hear within the next two weeks, by the end of the day > March 14. > > Yours, > Joel (and Brian) > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From hartmans@mit.edu Tue Mar 15 14:57:00 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A653A6EF4 for ; Tue, 15 Mar 2011 14:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.918 X-Spam-Level: X-Spam-Status: No, score=-102.918 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ+y3Q9Q+Vh4 for ; Tue, 15 Mar 2011 14:56:59 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 778853A6EEF for ; Tue, 15 Mar 2011 14:56:59 -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 D65B4203A2 for ; Tue, 15 Mar 2011 17:55:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6F0D2437D; Tue, 15 Mar 2011 17:57:42 -0400 (EDT) From: Sam Hartman To: karp@ietf.org Date: Tue, 15 Mar 2011 17:57:42 -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] Updated election for draft-hartman-karp-mrkmp X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 21:57:00 -0000 Last IETF, Dacheng and I presented a cut at a multicast key management protocol. We received comments that there were some bugs in our election process. This IETF, Dacheng has focused significant effort on the election protocol and I think we have a much better understanding of how to accomplish this. We'd appreciate your comments. From jmh@joelhalpern.com Mon Mar 21 10:05:01 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184EB28C156 for ; Mon, 21 Mar 2011 10:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FU4I1Pi7QIjN for ; Mon, 21 Mar 2011 10:05:00 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 75E5728C0F4 for ; Mon, 21 Mar 2011 10:05:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6333D4300EC for ; Mon, 21 Mar 2011 10:06:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-193.clppva.btas.verizon.net [71.161.51.193]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 0A4F843004E for ; Mon, 21 Mar 2011 10:06:32 -0700 (PDT) Message-ID: <4D87859E.5030504@joelhalpern.com> Date: Mon, 21 Mar 2011 13:06:38 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "karp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Minute taker X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 21 Mar 2011 17:05:01 -0000 The KARP working group is meeting Friday morning in Prague. I would really like to skip the 10 minute delay while we twist someones arm to take minutes. IS THERE A VOLUNTEER TO TAKE MINUTES?? !!! Thank you, Joel From gregory.ietf@gmail.com Mon Mar 28 17:51:51 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071783A6A9F for ; Mon, 28 Mar 2011 17:51:51 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMCYwfQSOHQi for ; Mon, 28 Mar 2011 17:51:49 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 7C2BC3A696D for ; Mon, 28 Mar 2011 17:51:49 -0700 (PDT) Received: by iye19 with SMTP id 19so4190744iye.31 for ; Mon, 28 Mar 2011 17:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z99qGrHbeOgqlSJcBPO3JHPdTtwpg4+K3W/BOCp0T4c=; b=AtYC5dlc5KnbBvZpMnfYeTWaXbJLdEn7c8XpsWaYqM85EKabDFNQbdc5+rizZgPAIP zes/qnEh13OCNENtb73J4YTPW6pC6U3dySGpe0JkpKU+0ssjfJXhNErqUFpcGfe6iA0K JBtaHMPBiKxzAZWLelatjC3wVy9CKVol1HHXw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Xkn1qARqdgoSQduExK1cC+MLgCGfR9P+Uc9s/s0BHjTzbOPr4ES09vZQOgb+XZR7Zv DbDYj4kFbvOJgmkcxc2snwJrKtHJa5B/wfjsybp+4IYJiMTFpIH4+iOvtiW0S5XC3Pdf AdqmbqF00PLNnNxvURREY+bzUy7Sm68yYmX2U= MIME-Version: 1.0 Received: by 10.231.55.90 with SMTP id t26mr4670857ibg.116.1301360007168; Mon, 28 Mar 2011 17:53:27 -0700 (PDT) Received: by 10.231.66.18 with HTTP; Mon, 28 Mar 2011 17:53:27 -0700 (PDT) In-Reply-To: <4D6C2254.5000602@joelhalpern.com> References: <4D6C2254.5000602@joelhalpern.com> Date: Mon, 28 Mar 2011 17:53:27 -0700 Message-ID: From: Gregory Lebovitz To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=000e0cd5f0d4f3cb1e049f947c2e Cc: "karp@ietf.org" Subject: Re: [karp] WG LC: draft-ietf-karp-threats-reqs-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 00:51:51 -0000 --000e0cd5f0d4f3cb1e049f947c2e Content-Type: text/plain; charset=ISO-8859-1 I support publication. Re: Ran's comments: - yes, it should be INFORMATIONAL, not proposed standard - I agree that any new KARP work ought to be judged both on its own merits AND against the reqs. Specifically, some new KARP work should show how it does and does not meet the threats-reqs, and if NOT, then it must justify why. This way the community can be better informed about the new work, and understand better how the new work fits into the existing effort. Make sense? Gregory. On Mon, Feb 28, 2011 at 2:31 PM, Joel M. Halpern wrote: > This document: > http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ > The Threat Analysis and Requirements for Cryptographic Authentication of > Routing Protocols' Transports > is a working group document. It is a charter deliverable. There have been > no comments or discussion recently. > > The chairs are therefore asking for a WG last call, with the view of > sending this to our AD for publication as an Proposed Standard RFC. > This Last Call will last 2 weeks, ending at the end of the day March 14th. > > Yours, > Joel (and Brian) > > PS: which is how I should have signed the last one. Sorry, bad habits. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --000e0cd5f0d4f3cb1e049f947c2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support publication.

Re: Ran's comments:
=A0- yes, it should be INFORMATIONAL, not proposed standard
=A0-= I agree that any new KARP work ought to be judged both on its own merits A= ND against the reqs. Specifically, some new KARP work should show how it do= es and does not meet the threats-reqs, and if NOT, then it must justify why= . This way the community can be better informed about the new work, and und= erstand better how the new work fits into the existing effort. Make sense?<= /div>

Gregory.

On Mo= n, Feb 28, 2011 at 2:31 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
This document:
http://datatracker.ietf.org/doc/draft-ietf-karp-threats-re= qs/
The Threat Analysis and Requirements for Cryptographic Authentication of Ro= uting Protocols' Transports
is a working group document. =A0It is a charter deliverable. =A0There have = been no comments or discussion recently.

The chairs are therefore asking for a WG last call, with the view of sendin= g this to our AD for publication as an Proposed Standard RFC.
This Last Call will last 2 weeks, ending at the end of the day March 14th.<= br>
Yours,
Joel (and Brian)

PS: which is how I should have signed the last one. =A0Sorry, bad habits. _______________________________________________
karp mailing list
karp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/karp



--
----
IETF related em= ail from
Gregory M. Lebovitz
Juniper Networks
--000e0cd5f0d4f3cb1e049f947c2e-- From gregory.ietf@gmail.com Mon Mar 28 18:07:36 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF9028C0F1 for ; Mon, 28 Mar 2011 18:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.484 X-Spam-Level: X-Spam-Status: No, score=-103.484 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlVtlkC7ljeK for ; Mon, 28 Mar 2011 18:07:35 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 19D103A6AAB for ; Mon, 28 Mar 2011 18:07:35 -0700 (PDT) Received: by iwn39 with SMTP id 39so4238942iwn.31 for ; Mon, 28 Mar 2011 18:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Sb16TZ+e1r2/XsrDtIB7AJ3uI40ExRqcJ1aq+uosdB8=; b=I7UwEUgXSaUe12idYevj7gPDNXerLLdc7g4Fw74SXQMGnrkXFudKQcHkhve/cgLZ5t rEtQtbowMc8KOaHhx8FZMVzBpQJ1SNzmCpeE60vRUsBkxf2POT/Fltn5r9WMq4qIhOZO guKDy0qsF7VzNteo01VNjG4b2zMhxvrXPZqN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V6p2xUzVHna5i0Zbvz2COnLD/Dll4clffTIOdY8QTP5wwOlu1xN0LZ0p30JhG4W2Rj +g1QFLkK19N25+sEFebJHko038Fxj5oLuMGENG232GNbWYBqaoUHJYW0aRcPno52jmsi 93yJsRMFSvi+QH575qTuN+g3bBaF9UbYHPRhU= MIME-Version: 1.0 Received: by 10.231.184.156 with SMTP id ck28mr4679687ibb.141.1301360952826; Mon, 28 Mar 2011 18:09:12 -0700 (PDT) Received: by 10.231.66.18 with HTTP; Mon, 28 Mar 2011 18:09:12 -0700 (PDT) In-Reply-To: References: <4D6C2164.8020308@joelhalpern.com> Date: Mon, 28 Mar 2011 18:09:12 -0700 Message-ID: From: Gregory Lebovitz To: Sam Hartman Content-Type: multipart/alternative; boundary=0050450174aa515a61049f94b5a9 Cc: "karp@ietf.org" Subject: Re: [karp] WG Last Call: draft-ietf-karp-design-guide-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 01:07:36 -0000 --0050450174aa515a61049f94b5a9 Content-Type: text/plain; charset=ISO-8859-1 I know we are passed the end of WG LC, but fwiw, I support publication as informational. I also agree with Sam's comments below, for the most part. I think we need to publish where we are today as RFC, and then be willing to start a -bis as necessary according to the learning we gain from actually DOING KARP on a few protocols. Let's not be too terribly rigid, but lets do try to follow a process, and not abandon that process until we have a good data that shows it needs alterations, and decision on what those alterations will be. I'll be participating on Friday via remote audio and chat, as I'm not in Prague. Gregory On Tue, Mar 1, 2011 at 5:34 AM, Sam Hartman wrote: > I support publication of this document as informational thinking on > where we are now. > We haven't had a lot of experience with the process described in this > document for the phased approach and for the deliverables at each stage. > I think it's fine to snapshot our progress now, and move on with > actually doing the work. > > I don't think we have enough confidence in this document that we should > be rigidly bound by it. > I agree it represents our current thinking. > However, I'd like to retain flexibility to make possibly significant > changes to the details of the process as we get more experience. > > So, if the purpose of publishing this is to describe where we are that's > great. > If the purpose is to close off refinements of the process we're going to > use then I think it is premature. > > Note that our charter does have constraints on the process we're going > to use; I support those constraints. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --0050450174aa515a61049f94b5a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I know we are passed the end of WG LC, but fwiw, I support publication as i= nformational.=A0

I also agree with Sam's comments be= low, for the most part. I think we need to publish where we are today as RF= C, and then be willing to start a -bis as necessary according to the learni= ng we gain from actually DOING KARP on a few protocols. Let's not be to= o terribly rigid, but lets do try to follow a process, and not abandon that= process until we have a good data that shows it needs alterations, and dec= ision on what those alterations will be.

I'll be participating on Friday via remote audio an= d chat, as I'm not in Prague.

Gregory


On Tue, Mar 1, 2011 at 5:34 AM, Sam Ha= rtman <hartma= ns-ietf@mit.edu> wrote:
I support publication of this document as i= nformational thinking on
where we are now.
We haven't had a lot of experience with the process described in this document for the phased approach and for the deliverables at each stage. I think it's fine to snapshot our progress now, and move on with
actually doing the work.

I don't think we have enough confidence in this document that we should=
be rigidly bound by it.
I agree it represents our current thinking.
However, I'd like to retain flexibility to make possibly significant changes to the details of the process as we get more experience.

So, if the purpose of publishing this is to describe where we are that'= s
great.
If the purpose is to close off refinements of the process we're going t= o
use then I think it is premature.

Note that our charter does have constraints on the process we're going<= br> to use; I support those constraints.
_________________________________________= ______
karp mailing list
karp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/karp



--
----
IET= F related email from
Gregory M. Lebovitz
Juniper Networks
--0050450174aa515a61049f94b5a9-- From liang.xiaoping@zte.com.cn Tue Mar 29 05:07:45 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5961828C168 for ; Tue, 29 Mar 2011 05:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.688 X-Spam-Level: X-Spam-Status: No, score=-100.688 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymbkeosi3JTi for ; Tue, 29 Mar 2011 05:07:42 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 5AECC28C163 for ; Tue, 29 Mar 2011 05:07:42 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510536813104; Tue, 29 Mar 2011 20:06:52 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 88125.536813104; Tue, 29 Mar 2011 19:58:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p2TC98rl007077 for ; Tue, 29 Mar 2011 20:09:08 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: To: karp@ietf.org MIME-Version: 1.0 X-KeepSent: 2B0F57E6:44C6138C-48257862:00415EA2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Tue, 29 Mar 2011 20:09:14 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-29 20:09:09, Serialize complete at 2011-03-29 20:09:09 Content-Type: multipart/alternative; boundary="=_alternative 0042C0E448257862_=" X-MAIL: mse01.zte.com.cn p2TC98rl007077 Subject: Re: [karp] Welcome to discussion and comments on draft-liang-karp-negotiation-kmp-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 12:07:45 -0000 This is a multipart message in MIME format. --=_alternative 0042C0E448257862_= Content-Type: text/plain; charset="US-ASCII" Hi all, Since I made some typo with XML in 00 version of the draft negotiation-kmp, which resulted in the missing of one sepcific reason for KMPs, i.e., deployment and incremental deployment, I update the draft to 01 version, just correct the typo, with no difference from the 00 version, in order to try to keep the rule of IETF80 that draft submitted in 00 version is due by March 7. The following is the link to the draft: http://www.ietf.org/id/draft-liang-karp-negotiation-kmp-01.txt Best regards, Ellen (Xiaoping Liang) 2011-03-15 11:33 Hi all, Here is a new draft on negotiation in KMPs, which is inspired by the discussion on negotiation initiated by Sam. Discussion and comments are welcome! http://www.ietf.org/id/draft-liang-karp-negotiation-kmp-00.txt Negotiation is one prominent capability of keying managament protocols (KMPs), especially automated KMPs for Routing Protocols. This document discusses negotiation in KMPs, which includes the reasons for negotiation in KMPs, concerns and possible solutions when using negotiation, and several types of negotiation in KMPs. Best regards, Ellen (Xiaoping Liang) karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0042C0E448257862_= Content-Type: text/html; charset="US-ASCII"
Hi all,

Since I made some typo with XML in 00 version of the draft negotiation-kmp, which resulted in the missing of one sepcific reason for KMPs, i.e., deployment and incremental deployment, I update the draft to 01 version, just correct the typo, with no difference from the 00 version, in order to try to keep the rule of IETF80 that draft submitted in 00 version is due by March 7.

The following is the link to the draft:
http://www.ietf.org/id/draft-liang-karp-negotiation-kmp-01.txt

Best regards,
Ellen (Xiaoping Liang)
 
 

2011-03-15 11:33

Hi all,

Here is a new draft on negotiation in KMPs, which is inspired by the discussion on negotiation initiated by Sam. Discussion and comments are welcome!

http://www.ietf.org/id/draft-liang-karp-negotiation-kmp-00.txt

Negotiation is one prominent capability of keying managament protocols (KMPs), especially automated KMPs for Routing Protocols. This document discusses negotiation in KMPs, which includes the reasons for negotiation in KMPs, concerns and possible solutions when using negotiation, and several types of negotiation in KMPs.

Best regards,
Ellen (Xiaoping Liang)


karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0042C0E448257862_=-- From manav.bhatia@alcatel-lucent.com Tue Mar 29 05:44:01 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7970E3A67DB for ; Tue, 29 Mar 2011 05:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.814 X-Spam-Level: X-Spam-Status: No, score=-6.814 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zBssi6qAQHb for ; Tue, 29 Mar 2011 05:44:00 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 72B4F3A63CA for ; Tue, 29 Mar 2011 05:44:00 -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 p2TCjX6M006853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Mar 2011 07:45:36 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2TCjW13032200 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Mar 2011 18:15:33 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 29 Mar 2011 18:15:32 +0530 From: "Bhatia, Manav (Manav)" To: Mahesh Jethanandani , "karp@ietf.org" Date: Tue, 29 Mar 2011 18:15:30 +0530 Thread-Topic: [karp] Fwd: New Version Notification for draft-mahesh-bgp-ldp-msdp-analysis-00 Thread-Index: AcvXwoWW8Rif6eKzROmQ678erKiuOQWQ9mrA Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF668BE@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4D6C6AD4.2070408@cisco.com> In-Reply-To: <4D6C6AD4.2070408@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Keyur Patel Subject: Re: [karp] Fwd: New Version Notification for draft-mahesh-bgp-ldp-msdp-analysis-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 12:44:01 -0000 Hi Mahesh, =20 I quickly looked at the document and couldn't find the gap analysis that th= is document promises to provide in the Introduction. =20 I was expecting some text saying that "while we have TCP-AO for BGP, there = still are the following issues that exist with BGP .. blah blah" - I couldn= 't find any such text. In fact, I am not even sure I understand the gaps th= at you want the WG to look at. =20 Further when doing gap analysis in sec 4 you state the following in your do= cument: =20 "The session layer that runs on TCP needs to protect itself by running TCP = LISTEN only on interfaces on which its peers have been discovered or that a= re configured to expect sessions on." I am a little confused with this - How would BGP know which interface to ex= pect a TCP packet from for its IBGP peer that's peering using the loopback = IP address? Further you say that BGP, LDP, etc are vulnerable to spoofing and MITM atta= cks. Can you explain how this can happen when these use TCP-AO? The draft also talks about privacy issues in some sections which I believe = can completely be removed. Cheers, Manav ________________________________ From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Ma= hesh Jethanandani Sent: Tuesday, March 01, 2011 9.11 AM To: karp@ietf.org Cc: Keyur Patel Subject: [karp] Fwd: New Version Notification for draft-mahesh-bgp-ldp-msd= p-analysis-00 =09 =09 The authors have submitted a draft that does a analysis of the current sta= te of the three routing protocols per the karp analysis guide. Please revie= w the draft and provide comments on it. =09 Thanks. =09 --mj =09 -------- Original Message -------- =09 =09 A new version of I-D, draft-mahesh-bgp-ldp-msdp-analysis-00.txt has been s= uccessfully submitted by Mahesh Jethanandani and posted to the IETF reposit= ory. =09 Filename: draft-mahesh-bgp-ldp-msdp-analysis Revision: 00 Title: Analysis of BGP, LDP and MSDP Security According to KARP = Design Guide Creation_date: 2011-02-25 WG ID: Independent Submission Number_of_pages: 13 =09 Abstract: This document analyzes BGP, LDP and MSDP according to guidelines set forth in section 4.2 of [draft-ietf-karp-design-guide]. = =20 =09 =09 The IETF Secretariat. =09 =09 =09 From mahesh@cisco.com Wed Mar 30 04:25:19 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2082E28C13B for ; Wed, 30 Mar 2011 04:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cONTDswfA4dO for ; Wed, 30 Mar 2011 04:25:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 594E828C160 for ; Wed, 30 Mar 2011 04:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mahesh@cisco.com; l=11128; q=dns/txt; s=iport; t=1301484414; x=1302694014; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ExJkHnSzrFWE0OwGOZu3mV+mvR/EmfmoAoQttpecSEU=; b=hvAbEPG6BcOWeH7qVOZuywfChJjSrBYNXopcGMnV3sgOGRneZ6jLRnnI LZzSrPNB34fahxEiAgORHG6/l99luLCESpIEBvN28Y6ztXWc5ejN38MA5 94TrKMvfqfpvBpsCeTlj3JIwz8QW0mdnkPLomCYA2E67BhFdGTbjKM7vt 8=; X-IronPort-AV: E=Sophos;i="4.63,268,1299456000"; d="scan'208,217";a="81461011" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 30 Mar 2011 11:26:53 +0000 Received: from sjc-vpnasa-602.cisco.com (sjc-vpnasa-602.cisco.com [10.21.106.93]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2UBQoQg026196; Wed, 30 Mar 2011 11:26:51 GMT Message-ID: <4D9313F6.4040400@cisco.com> Date: Wed, 30 Mar 2011 04:28:54 -0700 From: Mahesh Jethanandani User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <4D6C6AD4.2070408@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFCF668BE@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFCF668BE@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------000402060102090200090606" Cc: "Keyur Patel \(keyupate\)" , karp@ietf.org Subject: Re: [karp] Fwd: New Version Notification fordraft-mahesh-bgp-ldp-msdp-analysis-00 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 11:25:19 -0000 This is a multi-part message in MIME format. --------------000402060102090200090606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Manav, Thanks for reading the draft and providing your feedback. On 3/29/11 5:45 AM, Bhatia, Manav (Manav) wrote: > > Hi Mahesh, > > I quickly looked at the document and couldn't find the gap analysis > that this document promises to provide in the Introduction. > > I was expecting some text saying that "while we have TCP-AO for BGP, > there still are the following issues that exist with BGP .. blah blah" > - I couldn't find any such text. In fact, I am not even sure I > understand the gaps that you want the WG to look at. > Our analysis found that from a protocol perspective LDP was the one that was vulnerable at the discovery time. For that there is a draft being presented at the meeting on Fri. And we will refer to it in our next version of the draft. > > > Further when doing gap analysis in sec 4 you state the following in > your document: > > "The session layer that runs on TCP needs to protect itself by running > TCP LISTEN only on interfaces on which its peers have been discovered > or that are configured to expect sessions on." > > I am a little confused with this - How would BGP know which interface > to expect a TCP packet from for its IBGP peer that's peering using the > loopback IP address? > That was written with eBGP in mind. Will update the draft. > > > Further you say that BGP, LDP, etc are vulnerable to spoofing and MITM > attacks. Can you explain how this can happen when these use TCP-AO? > You are right in pointing out that the protocols will not be subject to these attacks if using TCP-AO. In that sense it is more a observation of the current implementations (that do not use TCP-AO) than on where the standards are. We can remove that. > > > ________________________________ > > From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On > Behalf Of Mahesh Jethanandani > Sent: Tuesday, March 01, 2011 9.11 AM > To: karp@ietf.org > Cc: Keyur Patel > Subject: [karp] Fwd: New Version Notification for > draft-mahesh-bgp-ldp-msdp-analysis-00 > > > The authors have submitted a draft that does a analysis of the > current state of the three routing protocols per the karp analysis > guide. Please review the draft and provide comments on it. > > Thanks. > > --mj > > -------- Original Message -------- > > > > > A new version of I-D, > draft-mahesh-bgp-ldp-msdp-analysis-00.txt has been successfully > submitted by Mahesh Jethanandani and posted to the IETF repository. > > Filename: draft-mahesh-bgp-ldp-msdp-analysis > Revision: 00 > Title: Analysis of BGP, LDP and MSDP Security > According to KARP Design Guide > Creation_date: 2011-02-25 > WG ID: Independent Submission > Number_of_pages: 13 > > Abstract: > This document analyzes BGP, LDP and MSDP according to > guidelines set > forth in section 4.2 of [draft-ietf-karp-design-guide]. > > > > The IETF Secretariat. > > > > --------------000402060102090200090606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Manav,

Thanks for reading the draft and providing your feedback.

On 3/29/11 5:45 AM, Bhatia, Manav (Manav) wrote:
RE: [karp] Fwd: New Version Notification fordraft-mahesh-bgp-ldp-msdp-analysis-00

Hi Mahesh,

I quickly looked at the document and couldn't find the gap analysis that this document promises to provide in the Introduction.

I was expecting some text saying that "while we have TCP-AO for BGP, there still are the following issues that exist with BGP .. blah blah" - I couldn't find any such text. In fact, I am not even sure I understand the gaps that you want the WG to look at.

Our analysis found that from a protocol perspective LDP was the one that was vulnerable at the discovery time. For that there is a draft being presented at the meeting on Fri. And we will refer to it in our next version of the draft.


Further when doing gap analysis in sec 4 you state the following in your document:

"The session layer that runs on TCP needs to protect itself by running TCP LISTEN only on interfaces on which its peers have been discovered or that are configured to expect sessions on."

I am a little confused with this - How would BGP know which interface to expect a TCP packet from for its IBGP peer that's peering using the loopback IP address?

That was written with eBGP in mind. Will update the draft.


Further you say that BGP, LDP, etc are vulnerable to spoofing and MITM attacks. Can you explain how this can happen when these use TCP-AO?

You are right in pointing out that the protocols will not be subject to these attacks if using TCP-AO. In that sense it is more a observation of the current implementations (that do not use TCP-AO) than on where the standards are. We can remove that.


________________________________

        From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Mahesh Jethanandani
        Sent: Tuesday, March 01, 2011 9.11 AM
        To: karp@ietf.org
        Cc: Keyur Patel
        Subject: [karp] Fwd: New Version Notification for draft-mahesh-bgp-ldp-msdp-analysis-00
       
       
        The authors have submitted a draft that does a analysis of the current state of the three routing protocols per the karp analysis guide. Please review the draft and provide comments on it.
       
        Thanks.
       
        --mj
       
        -------- Original Message --------
       
       


        A new version of I-D, draft-mahesh-bgp-ldp-msdp-analysis-00.txt has been successfully submitted by Mahesh Jethanandani and posted to the IETF repository.
       
        Filename:        draft-mahesh-bgp-ldp-msdp-analysis
        Revision:        00
        Title:           Analysis of BGP, LDP and MSDP Security According to KARP Design Guide
        Creation_date:   2011-02-25
        WG ID:           Independent Submission
        Number_of_pages: 13
       
        Abstract:
        This document analyzes BGP, LDP and MSDP according to guidelines set
        forth in section 4.2 of [draft-ietf-karp-design-guide].
                                                                                        
       
       
        The IETF Secretariat.
       
       
       

--------------000402060102090200090606-- From manav.bhatia@alcatel-lucent.com Wed Mar 30 05:23:33 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7621628C130 for ; Wed, 30 Mar 2011 05:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=-4.895, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+4wOZuUO6xi for ; Wed, 30 Mar 2011 05:23:30 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 976763A683E for ; Wed, 30 Mar 2011 05:23:30 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p2UCOvWp026001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2011 07:25:00 -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 p2UCOuEi001639 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Mar 2011 17:54:56 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 30 Mar 2011 17:54:56 +0530 From: "Bhatia, Manav (Manav)" To: zhenglianshu 50128 Date: Wed, 30 Mar 2011 17:54:54 +0530 Thread-Topic: =?gb2312?B?u9i4tDpSZTogW2thcnBdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u?= =?gb2312?B?IGZvcmRyYWZ0LW1haGVzaC1iZ3AtbGRwLW1zZHAtYW5hbHlzaXMtMDA=?= Thread-Index: Acvu1N88LS0WgZJKRH22gtnerTK5YQAAFfvw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF66B04@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4D6C6AD4.2070408@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFCF668BE@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D9313F6.4040400@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: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "Keyur Patel \(keyupate\)" , "mach.chen@huawei.com" , "karp@ietf.org" Subject: Re: [karp] =?gb2312?b?u9i4tDpSZTogIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZp?= =?gb2312?b?Y2F0aW9uIGZvcmRyYWZ0LW1haGVzaC1iZ3AtbGRwLW1zZHAtYW5hbHlzaXMt?= =?gb2312?b?MDA=?= X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 12:23:34 -0000 VmVybywNCg0KSWYgeW91IGxvb2sgYXQgU2VjdGlvbiA0LCB0aGVuIHRoaXMgcGFydGljdWxhciBz dGF0ZW1lbnQgYWJvdXQgQkdQLCBMRFAgYmVpbmcgdnVsbmVyYWJsZSB0byBzcG9vZmluZyBhbmQg TUlUTSB3YXMgbWFkZSBpbiBjb250ZXh0IG9mIFRDUCwgYW5kIHRodXMgbXkgY29tbWVudC4gDQoN CkNoZWVycywgTWFuYXYNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB6 aGVuZ2xpYW5zaHUgNTAxMjggW21haWx0bzp2ZXJvemhlbmdAaHVhd2VpLmNvbV0gDQo+IFNlbnQ6 IFdlZG5lc2RheSwgTWFyY2ggMzAsIDIwMTEgNS41MCBQTQ0KPiBUbzogQmhhdGlhLCBNYW5hdiAo TWFuYXYpDQo+IENjOiBNYWhlc2ggSmV0aGFuYW5kYW5pOyBLZXl1ciBQYXRlbCAoa2V5dXBhdGUp OyANCj4ga2FycEBpZXRmLm9yZzsgbWFjaC5jaGVuQGh1YXdlaS5jb20NCj4gU3ViamVjdDogu9i4 tDpSZTogW2thcnBdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIA0KPiBmb3JkcmFmdC1t YWhlc2gtYmdwLWxkcC1tc2RwLWFuYWx5c2lzLTAwDQo+IA0KPiBGdXJ0aGVyIHlvdSBzYXkgdGhh dCBCR1AsIExEUCwgZXRjIGFyZSB2dWxuZXJhYmxlIHRvIHNwb29maW5nIA0KPiBhbmQgTUlUTSBh dHRhY2tzLiBDYW4geW91IGV4cGxhaW4gaG93IHRoaXMgY2FuIGhhcHBlbiB3aGVuIA0KPiB0aGVz ZSB1c2UgVENQLUFPPw0KPiANCj4gVmVyby0+IEVzdGFibGlzaGVkIExEUCBzZXNzaW9uIGNvdWxk IGJlIHRvcmUgZG93biBieSBzcG9vZmVkIA0KPiBIZWxsbywgYnkgc3BlY2lmeWluZyBhIHNtYWxs ZXIgSG9sZCBUaW1lIG9yIGNoYW5naW5nIHRoZSANCj4gVHJhbnNwb3J0IEFkZHJlc3MuDQo+IA0K PiAgVENQLUFPIGRvIG5vdCBoZWxwIHNpbmNlIExEUCBIZWxsbyBtZXNzYWdlcyBhcmUgc2VudCB1 c2luZyBVRFAuDQo+IA0KPiBkcmFmdC16aGVuZy1tcGxzLWxkcC1oZWxsby1jcnlwdG8tYXV0aC0w MWRlY3JpYmVzIHRoaXMgDQo+IHByb2JsZW0gYW5kIGludHJvZHVjZXMgYSBuZXcgQ3J5cHRvZ3Jh cGhpYyBBdXRoZW50aWNhdGlvbiANCj4gVExWLiBJIHdpbGwgcHJlc2VudCBpdCBvbiBGcmlkYXks IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gLS0t LS0g1K3Tyrz+IC0tLS0tDQo+ILeivP7IyzogTWFoZXNoIEpldGhhbmFuZGFuaSA8bWFoZXNoQGNp c2NvLmNvbT4NCj4gyNXG2jog0MfG2sj9LCDI/dTCIDMwyNUsIDIwMTEgz8LO5zE6MjcNCj4g1vfM 4jogUmU6IFtrYXJwXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiANCj4gZm9yZHJhZnQt bWFoZXNoLWJncC1sZHAtbXNkcC1hbmFseXNpcy0wMA0KPiDK1bz+yMs6ICJCaGF0aWEsIE1hbmF2 IChNYW5hdikiIDxtYW5hdi5iaGF0aWFAYWxjYXRlbC1sdWNlbnQuY29tPg0KPiCzrcvNOiAiS2V5 dXIgUGF0ZWwgKGtleXVwYXRlKSIgPGtleXVwYXRlQGNpc2NvLmNvbT4sIGthcnBAaWV0Zi5vcmcN Cj4gDQo+ID4gTWFuYXYsDQo+ID4gDQo+ID4gVGhhbmtzIGZvciByZWFkaW5nIHRoZSBkcmFmdCBh bmQgcHJvdmlkaW5nIHlvdXIgZmVlZGJhY2suDQo+ID4gDQo+ID4gT24gMy8yOS8xMSA1OjQ1IEFN LCBCaGF0aWEsIE1hbmF2IChNYW5hdikgd3JvdGU6DQo+ID4gPg0KPiA+ID4gSGkgTWFoZXNoLA0K PiA+ID4NCj4gPiA+IEkgcXVpY2tseSBsb29rZWQgYXQgdGhlIGRvY3VtZW50IGFuZCBjb3VsZG4n dCBmaW5kIHRoZSBnYXAgDQo+ID4gYW5hbHlzaXMgDQo+ID4gPiB0aGF0IHRoaXMgZG9jdW1lbnQg cHJvbWlzZXMgdG8gcHJvdmlkZSBpbiB0aGUgSW50cm9kdWN0aW9uLg0KPiA+ID4NCj4gPiA+IEkg d2FzIGV4cGVjdGluZyBzb21lIHRleHQgc2F5aW5nIHRoYXQgIndoaWxlIHdlIGhhdmUgVENQLUFP IGZvciANCj4gPiBCR1AsIA0KPiA+ID4gdGhlcmUgc3RpbGwgYXJlIHRoZSBmb2xsb3dpbmcgaXNz dWVzIHRoYXQgZXhpc3Qgd2l0aCBCR1AgLi4gYmxhaCANCj4gPiBibGFoIiANCj4gPiA+IC0gSSBj b3VsZG4ndCBmaW5kIGFueSBzdWNoIHRleHQuIEluIGZhY3QsIEkgYW0gbm90IGV2ZW4gc3VyZSBJ IA0KPiA+ID4gdW5kZXJzdGFuZCB0aGUgZ2FwcyB0aGF0IHlvdSB3YW50IHRoZSBXRyB0byBsb29r IGF0Lg0KPiA+ID4NCj4gPiBPdXIgYW5hbHlzaXMgZm91bmQgdGhhdCBmcm9tIGEgcHJvdG9jb2wg cGVyc3BlY3RpdmUgTERQIHdhcyB0aGUgb25lIA0KPiA+IHRoYXQgDQo+ID4gd2FzIHZ1bG5lcmFi bGUgYXQgdGhlIGRpc2NvdmVyeSB0aW1lLiBGb3IgdGhhdCB0aGVyZSBpcyBhIGRyYWZ0IA0KPiA+ IGJlaW5nIA0KPiA+IHByZXNlbnRlZCBhdCB0aGUgbWVldGluZyBvbiBGcmkuIEFuZCB3ZSB3aWxs IHJlZmVyIHRvIGl0IGluIG91ciANCj4gPiBuZXh0IA0KPiA+IHZlcnNpb24gb2YgdGhlIGRyYWZ0 Lg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBGdXJ0aGVyIHdoZW4gZG9pbmcgZ2FwIGFuYWx5c2lzIGlu IHNlYyA0IHlvdSBzdGF0ZSB0aGUgZm9sbG93aW5nIA0KPiA+IGluIA0KPiA+ID4geW91ciBkb2N1 bWVudDoNCj4gPiA+DQo+ID4gPiAiVGhlIHNlc3Npb24gbGF5ZXIgdGhhdCBydW5zIG9uIFRDUCBu ZWVkcyB0byBwcm90ZWN0IGl0c2VsZiBieSANCj4gPiBydW5uaW5nIA0KPiA+ID4gVENQIExJU1RF TiBvbmx5IG9uIGludGVyZmFjZXMgb24gd2hpY2ggaXRzIHBlZXJzIGhhdmUgYmVlbiANCj4gPiBk aXNjb3ZlcmVkIA0KPiA+ID4gb3IgdGhhdCBhcmUgY29uZmlndXJlZCB0byBleHBlY3Qgc2Vzc2lv bnMgb24uIg0KPiA+ID4NCj4gPiA+IEkgYW0gYSBsaXR0bGUgY29uZnVzZWQgd2l0aCB0aGlzIC0g SG93IHdvdWxkIEJHUCBrbm93IHdoaWNoIA0KPiA+IGludGVyZmFjZSANCj4gPiA+IHRvIGV4cGVj dCBhIFRDUCBwYWNrZXQgZnJvbSBmb3IgaXRzIElCR1AgcGVlciB0aGF0J3MgcGVlcmluZyANCj4g PiB1c2luZyB0aGUgDQo+ID4gPiBsb29wYmFjayBJUCBhZGRyZXNzPw0KPiA+ID4NCj4gPiBUaGF0 IHdhcyB3cml0dGVuIHdpdGggZUJHUCBpbiBtaW5kLiBXaWxsIHVwZGF0ZSB0aGUgZHJhZnQuDQo+ ID4gPg0KPiA+ID4NCj4gPiA+IEZ1cnRoZXIgeW91IHNheSB0aGF0IEJHUCwgTERQLCBldGMgYXJl IHZ1bG5lcmFibGUgdG8gc3Bvb2ZpbmcgYW5kIA0KPiA+IE1JVE0gDQo+ID4gPiBhdHRhY2tzLiBD YW4geW91IGV4cGxhaW4gaG93IHRoaXMgY2FuIGhhcHBlbiB3aGVuIHRoZXNlIA0KPiB1c2UgVENQ LUFPPw0KPiA+ID4NCj4gPiBZb3UgYXJlIHJpZ2h0IGluIHBvaW50aW5nIG91dCB0aGF0IHRoZSBw cm90b2NvbHMgd2lsbCBub3QgYmUgDQo+ID4gc3ViamVjdCB0byANCj4gPiB0aGVzZSBhdHRhY2tz IGlmIHVzaW5nIFRDUC1BTy4gSW4gdGhhdCBzZW5zZSBpdCBpcyBtb3JlIGEgDQo+ID4gb2JzZXJ2 YXRpb24gb2YgDQo+ID4gdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zICh0aGF0IGRvIG5vdCB1 c2UgVENQLUFPKSB0aGFuIG9uIHdoZXJlIA0KPiA+IHRoZSANCj4gPiBzdGFuZGFyZHMgYXJlLiBX ZSBjYW4gcmVtb3ZlIHRoYXQuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gPg0KPiA+ID4gICAgICAgICBGcm9tOiBrYXJwLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzprYXJwLQ0KPiA+IGJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPiA+ID4g QmVoYWxmIE9mIE1haGVzaCBKZXRoYW5hbmRhbmkNCj4gPiA+ICAgICAgICAgU2VudDogVHVlc2Rh eSwgTWFyY2ggMDEsIDIwMTEgOS4xMSBBTQ0KPiA+ID4gICAgICAgICBUbzoga2FycEBpZXRmLm9y Zw0KPiA+ID4gICAgICAgICBDYzogS2V5dXIgUGF0ZWwNCj4gPiA+ICAgICAgICAgU3ViamVjdDog W2thcnBdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gPiA+IGRyYWZ0LW1h aGVzaC1iZ3AtbGRwLW1zZHAtYW5hbHlzaXMtMDANCj4gPiA+DQo+ID4gPg0KPiA+ID4gICAgICAg ICBUaGUgYXV0aG9ycyBoYXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IHRoYXQgZG9lcyBhIGFuYWx5c2lz IA0KPiA+IG9mIHRoZSANCj4gPiA+IGN1cnJlbnQgc3RhdGUgb2YgdGhlIHRocmVlIHJvdXRpbmcg cHJvdG9jb2xzIHBlciB0aGUga2FycCANCj4gPiBhbmFseXNpcyANCj4gPiA+IGd1aWRlLiBQbGVh c2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQgcHJvdmlkZSBjb21tZW50cyBvbiBpdC4NCj4gPiA+DQo+ ID4gPiAgICAgICAgIFRoYW5rcy4NCj4gPiA+DQo+ID4gPiAgICAgICAgIC0tbWoNCj4gPiA+DQo+ ID4gPiAgICAgICAgIC0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NCj4gPiA+DQo+ ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAgICAgICAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCAN Cj4gPiA+IGRyYWZ0LW1haGVzaC1iZ3AtbGRwLW1zZHAtYW5hbHlzaXMtMDAudHh0IGhhcyBiZWVu IHN1Y2Nlc3NmdWxseSANCj4gPiA+IHN1Ym1pdHRlZCBieSBNYWhlc2ggSmV0aGFuYW5kYW5pIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgDQo+IHJlcG9zaXRvcnkuDQo+ID4gPg0KPiA+ID4gICAgICAg ICBGaWxlbmFtZTogICAgICAgIGRyYWZ0LW1haGVzaC1iZ3AtbGRwLW1zZHAtYW5hbHlzaXMNCj4g PiA+ICAgICAgICAgUmV2aXNpb246ICAgICAgICAwMA0KPiA+ID4gICAgICAgICBUaXRsZTogICAg ICAgICAgIEFuYWx5c2lzIG9mIEJHUCwgTERQIGFuZCBNU0RQIFNlY3VyaXR5IA0KPiA+ID4gQWNj b3JkaW5nIHRvIEtBUlAgRGVzaWduIEd1aWRlDQo+ID4gPiAgICAgICAgIENyZWF0aW9uX2RhdGU6 ICAgMjAxMS0wMi0yNQ0KPiA+ID4gICAgICAgICBXRyBJRDogICAgICAgICAgIEluZGVwZW5kZW50 IFN1Ym1pc3Npb24NCj4gPiA+ICAgICAgICAgTnVtYmVyX29mX3BhZ2VzOiAxMw0KPiA+ID4NCj4g PiA+ICAgICAgICAgQWJzdHJhY3Q6DQo+ID4gPiAgICAgICAgIFRoaXMgZG9jdW1lbnQgYW5hbHl6 ZXMgQkdQLCBMRFAgYW5kIE1TRFAgYWNjb3JkaW5nIHRvIA0KPiA+ID4gZ3VpZGVsaW5lcyBzZXQN Cj4gPiA+ICAgICAgICAgZm9ydGggaW4gc2VjdGlvbiA0LjIgb2YgW2RyYWZ0LWlldGYta2FycC1k ZXNpZ24tZ3VpZGVdLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gICAgICAgICBUaGUgSUVU RiBTZWNyZXRhcmlhdC4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gDQo+IA== From manav.bhatia@alcatel-lucent.com Wed Mar 30 08:24:49 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28D73A68B8; Wed, 30 Mar 2011 08:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.719 X-Spam-Level: X-Spam-Status: No, score=-6.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf06cUVizfYd; Wed, 30 Mar 2011 08:24:48 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id B48EF3A6847; Wed, 30 Mar 2011 08:24:48 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2UFQNTb015713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2011 10:26:25 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2UFQM2E004903 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Mar 2011 20:56:22 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 30 Mar 2011 20:56:22 +0530 From: "Bhatia, Manav (Manav)" To: "ospf@ietf.org" , "karp@ietf.org" Date: Wed, 30 Mar 2011 20:56:30 +0530 Thread-Topic: Securing the source IP in OSPF Thread-Index: Acvu7tgQXxp0oLMAR5uSduO0/re6CQ== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF66B2B@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [karp] Securing the source IP in OSPF X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 15:24:49 -0000 Hi, Because of paucity of time I did not discuss the IP header protection for O= SPF Security. I would request people to go through section 6 - "Mechanism to secure the I= P header" of http://tools.ietf.org/html/draft-bhatia-karp-ospf-ip-layer-pro= tection-03 and let us know if they have any concerns with that section. Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From glen.kent@gmail.com Wed Mar 30 12:47:58 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829893A6A7F; Wed, 30 Mar 2011 12:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCGPgQkLGB2V; Wed, 30 Mar 2011 12:47:57 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DCBDF3A68E0; Wed, 30 Mar 2011 12:47:55 -0700 (PDT) Received: by wwa36 with SMTP id 36so1372450wwa.13 for ; Wed, 30 Mar 2011 12:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sPrZT6nfkHukC1n5qIk3hRNWtiOfqhBCC6iAIgH2uoY=; b=S9O3wXEGKcbeq2Dzc+eNLBUEso0LugubIXsauP90e0FEZnk0v0XJiwIOfhVgUI1PQ6 5nvCMg5dMaBygqnxUBDD4OBMZz4VfU4iYdPvo3yysMEG8hoa3fulSXfZFdEecgEM9Vn5 cY0yUu1W4bRNFmOZHCKlQsES54U8FMDAqOwPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sBxLZGJvvuFI2WGslYAIW+8E1fjmUryVAuoOnNlG+FGJ+NW+5mXMOO9phQrEa5ltPR myN15xWDG5kdhWu8M2QpJ1Vics5ujCk9kA/3g2H1pFgV6XSPcs7G35hlrynIReh6cShe VPNQiYzMrMpWlSaI8P5AO8YIhRaoYfEW82b9k= MIME-Version: 1.0 Received: by 10.227.179.140 with SMTP id bq12mr1800675wbb.152.1301514573967; Wed, 30 Mar 2011 12:49:33 -0700 (PDT) Received: by 10.227.21.166 with HTTP; Wed, 30 Mar 2011 12:49:33 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFCF66B2B@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFCF66B2B@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 31 Mar 2011 01:19:33 +0530 Message-ID: From: Glen Kent To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "ospf@ietf.org" , "karp@ietf.org" Subject: Re: [karp] Securing the source IP in OSPF X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 19:47:58 -0000 Assuming that you will create a new Auth type i think this must be done unless the Apad has that fixed value because of some particular reason. I suspect that its just a random value that one usually finds in the security literature. It could have as well been 0xdeadbeef or 0xdeadbabe. Glen On Wed, Mar 30, 2011 at 8:56 PM, Bhatia, Manav (Manav) wrote: > > Hi, > > Because of paucity of time I did not discuss the IP header protection for OSPF Security. > > I would request people to go through section 6 - "Mechanism to secure the IP header" of http://tools.ietf.org/html/draft-bhatia-karp-ospf-ip-layer-protection-03 and let us know if they have any concerns with that section. > > Cheers, Manav > > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From manav.bhatia@alcatel-lucent.com Wed Mar 30 19:47:35 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BA33A6BF1; Wed, 30 Mar 2011 19:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.715 X-Spam-Level: X-Spam-Status: No, score=-6.715 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtgxtIaw0kOp; Wed, 30 Mar 2011 19:47:33 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id C65733A6BF0; Wed, 30 Mar 2011 19:47:33 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p2V2n9Ir007944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2011 21:49:11 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2V2n8kn008636 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Mar 2011 08:19:08 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 31 Mar 2011 08:19:08 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" , "ospf@ietf.org" Date: Thu, 31 Mar 2011 08:19:04 +0530 Thread-Topic: Regarding the replay attacks in routing protocols Thread-Index: AcvvTjK0vpHOKISuSFGYYUQpZJJEdA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCF66B6A@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [karp] Regarding the replay attacks in routing protocols X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 02:47:35 -0000 Hi, I would urge the members of KARP WG to go through the two anti-replay mecha= nisms described in http://tools.ietf.org/html/draft-bhatia-karp-ospf-ip-lay= er-protection-03 One extends the current sequence number space from 32 bits to 64 bits, wher= e the most significant 32 bits indicate the number of times the router has = cold booted. This value can be fetched from the non-volatile memory, flash = or some remote server (which may also possibly store the image, startup con= figs, etc). This value would be generic and we envisage all the other routi= ng and signaling protocols using this in future. Thus BFD, LDP, etc can ext= end their crypto sequence space and use this value as the most significant = 32 bits. The second entails a session ID that's maintained for each session and a no= nce that guarantees that you are speaking to a live router. The session ID = needs to be carried around in the protocol packets so that everyone knows t= he right context. The former is patently easier to implement. It requires no change on the re= ceiving side. It requires very little change on the sending side and specif= ically the protocol machinery. For extremely low end devices (in the near f= uture when small sensor devices may run OSPF to discover each other) that d= o not have nvram or cannot store information on some remote device we could= fall back to the second solution, or decide not to provide an inter-sessio= n replay attack protection mechanism. Alternately, we could progress both the solutions and let the market decide= which solution gains widespread usage. I am guessing that it will be the f= ormer because of its simplistic design. I thus propose to split the current= draft into two where the base document describes the boot count and the ot= her that explains the Session ID and Nonces. We already have a generic draft draft-bhz-karp-inter-session-replay-00 that= will be presented in KARP tomorrow. Once this is accepted as a WG item oth= er protocols (OSPF, BFD, LDP, etc) can refer to this and extend their seque= nce space to prevent against inter-session replay attacks. We already have an OSPF document draft-bhatia-karp-ospf-ip-layer-protection= -03 that has been extensively discussed on the mailing lists and we can tri= m it significantly if we just provide reference to the above KARP document. Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From curtis@occnc.com Thu Mar 31 01:22:15 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C883A6B2B; Thu, 31 Mar 2011 01:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x04LC7-09B+a; Thu, 31 Mar 2011 01:22:14 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 6BC923A6826; Thu, 31 Mar 2011 01:22:14 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p2V8NrGN047454; Thu, 31 Mar 2011 04:23:53 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103310823.p2V8NrGN047454@harbor.orleans.occnc.com> To: "karp@ietf.org" , "ospf@ietf.org" From: Curtis Villamizar Date: Thu, 31 Mar 2011 04:23:53 -0400 Sender: curtis@occnc.com X-Mailman-Approved-At: Thu, 31 Mar 2011 02:11:11 -0700 Cc: curtis@occnc.com Subject: [karp] draft-bhatia-karp-ospf-ip-layer-protection-03.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com 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, 31 Mar 2011 08:22:15 -0000 If a challenge response and session ID is going to be used, the nonce need not be carried after the session-id is negociated. The purpose of a nonce is to provide a challenge which the other end must encrypt and send back using a shared key or its private half of a public/private key pair. The nonce in both directions plus a session key must be exchanged and then after that the session key is used. To prevent replay, the session key and a monotonically increasing sequence number must be exchanged for subsequent packets. In pictures: session + challenge1 -> <- session + response1 + challenge2 session + response2 -> where: response1 = encrypt(session + challenge1) response2 = encrypt(session + challenge2) If you are going to keep that sort of method, then it needs to be used correctly. Only the session ID is needed after negociation. It would be better to exchange a session key rather than just a session ID. The reason to do this is so as not to use the same session key over a long period of time and to use the shared or public/private keys infrequently to provide very little data on which to try to reverse engineer the keys. I don't have strong feeling about whether this type of session ID should be used or whether the monotonicly increasing reboot count would be sufficient. I have some concerns about a CPU card going down or entire router catching fire and being replaced and not knowing what the reboot count was on the old CPU. The challenge/response has no requirement for a monotonically increasing reboot count variable. This may be a call for OSPF but KARP buy-in IMHO this conversation should be directed to either OSPF or KARP for now and not both but I cross posted since Manav cross posted a request to consider the security mechanisms in this draft. OTOH, this sort of session key negociation could be generic to other protocols (and quite frankly I borrowed the idea from the well documented kerberos tgt exchange and other challenge reponse use). Curtis From acee.lindem@gmail.com Thu Mar 31 02:03:18 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672633A6B2A for ; Thu, 31 Mar 2011 02:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGuulWYma1Im for ; Thu, 31 Mar 2011 02:03:17 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E607C28C0E1 for ; Thu, 31 Mar 2011 02:03:16 -0700 (PDT) Received: by wyb29 with SMTP id 29so2041149wyb.31 for ; Thu, 31 Mar 2011 02:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:subject:date:message-id:to :mime-version:x-mailer; bh=37Ca4toSjsfKZJWBfTz8SKsneQSpZ4/7DpybBpAYjXM=; b=FXvMakdp0oUps1bAe10R6NjWU6+47ThmHN+Sy1xFG/gA4/P/DFPwuC5+DhN8XfJMMC kPh6j+t5QE3SSIemctj/8kRfwXd5dU8BcrvVrSAhLZZpQ4376ZekNWgrm8J7Mzw8ofkX mkKHAkULlzc3U8jQ6w0dofA0bQavh3xbEAPu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; b=IB61YgEWeGznGASPwHeWRf6Q805qj5NGarsYAeSgqj/eiH4Anf9t17p5p2iA3KLCML n6fbDhnEB1pe3Inlbb8dvS/4UhHx0Dnb1y5WSu9DXm66DTJx9uBYYXM8vz8WWjj9neUy uppyDnzAfuFnsPmXXpXXrld5BvAhF2qh0bc4g= Received: by 10.227.173.66 with SMTP id o2mr2473972wbz.182.1301562295804; Thu, 31 Mar 2011 02:04:55 -0700 (PDT) Received: from dhcp-1457.meeting.ietf.org (dhcp-1457.meeting.ietf.org [130.129.20.87]) by mx.google.com with ESMTPS id u9sm524907wbg.17.2011.03.31.02.04.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2011 02:04:55 -0700 (PDT) From: Acee Lindem Content-Type: multipart/alternative; boundary=Apple-Mail-23--1014938270 Date: Thu, 31 Mar 2011 05:04:52 -0400 Message-Id: <040EE39D-6912-4F90-86A1-73943A3433BE@gmail.com> To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 31 Mar 2011 02:11:45 -0700 Subject: [karp] Comments on draft-ietf-karp-ospf-analysis-00.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 09:05:32 -0000 --Apple-Mail-23--1014938270 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Sam, Here are my comments: 1. Section 1: Change "interfeer" to "interfere". 2. Section 1.1: Change "thatt" to "that". 3. Section 1.1: Under "Neighbor Identification" - In OSPFv3, OSPFv3 = routers are always identified by router ID which is always protected. 4. Section 2.1: Change "beleived" to "believed". 5. Section 2.1: Change "streight" to "straight". 6. Section 2.1: "clock ticks since reboot, where each clock tick is on = the order = =20 of millisecionds" would be more accurate. 7. Section 2.2: Suggest "This index, along with other IPsec = facilities, provide" rather than current text. 8. Section 2.2: Since this section is meant to describe the current = state, the paragraph on replay should not discuss what could be done with = multiple SPIs. If we are describing solutions, we could just as well describe = keeping track of sequence numbers for different OSPF packet classes in section 2.1. 9. Section 3: The database exchange sequence number is never flooded. = Perhaps, "flooded" should be change to "included in OSPF Database = Description packets". 10. Section 3: Remove "or when all adjacencies are lost". It would be = very naive for an implementation to do this. 11. Section 4: I would change the last requirement to "information = needed to = =20 prioritize OSPF packets (the OSPF packet type) MUST be available to = the = =20 mechanisms providing relay protection." This is more important than = it being in a constant location. Also, should the document reference [I-D.ietf-rpsec-ospf-vuln]? It is highly unlikely that this document will ever be completed.=20 Thanks, Acee --Apple-Mail-23--1014938270 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
  2. Section 1.1: Change = "thatt" to "that".
  3. Section 1.1: Under "Neighbor = Identification" - In OSPFv3, OSPFv3 routers are
   =   always identified by router ID which is always = protected.
  4. Section 2.1: Change "beleived" to = "believed".
  5. Section 2.1: Change "streight" to = "straight".
  6. Section 2.1: "clock ticks since = reboot, where each clock tick is on the order       =                     =                     =                     =                 =  
     of millisecionds" would be more = accurate.
  7. Section 2.2: Suggest "This index, = along with other IPsec facilities, provide"
   =   rather than current text.
  8. Section 2.2: = Since this section is meant to describe the current state, = the
     paragraph on replay should not discuss = what could be done with multiple SPIs.
     If = we are describing solutions, we could just as well describe keeping = track of
     sequence numbers for different = OSPF packet classes in section 2.1.
  9. Section 3: = The database exchange sequence number is never flooded. = Perhaps,
     "flooded" should be change to = "included in OSPF Database Description packets".
 10. = Section 3: Remove "or when all adjacencies are lost". It would be very = naive
     for an implementation to do = this.
 11. Section 4: I would change the last requirement = to "information needed to             =                     =                     =                     =               =   
     prioritize OSPF packets (the = OSPF packet type) MUST be available to the         =                     =                     =                     =                     =  
     mechanisms providing relay = protection." This is more important than it
   =   being in a constant location.

Also, = should the document reference  In-reply-to: <201103310823.p2V8NrGN047454@harbor.orleans.occnc.com> X-Originating-IP: [172.24.2.41] To: "curtis@occnc.com" , "karp@ietf.org" , "ospf@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [karp] draft-bhatia-karp-ospf-ip-layer-protection-03.txt Thread-index: AQHL74SbbkDFhS7itUiiX4DV4riDqJRHLJyv X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <201103310823.p2V8NrGN047454@harbor.orleans.occnc.com> Subject: Re: [karp] draft-bhatia-karp-ospf-ip-layer-protection-03.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 09:31:49 -0000 >>It would be better to exchange a session key rather than just a >>session ID. The reason to do this is so as not to use the same >>session key over a long period of time and to use the shared or >>public/private keys infrequently to provide very little data on which >>to try to reverse engineer the keys. This draft assumes there is no automatic key management system provided. If there is a auto KMP, challenge/response solution will not be needed. Do you suggest that we should integrate a key negotiation process in OSPF? From curtis@occnc.com Thu Mar 31 04:54:28 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B470C3A6B3C; Thu, 31 Mar 2011 04:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDzJLqO2DjKL; Thu, 31 Mar 2011 04:54:27 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 8E4703A6875; Thu, 31 Mar 2011 04:54:27 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p2VBsmrB083180; Thu, 31 Mar 2011 07:54:48 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103311154.p2VBsmrB083180@harbor.orleans.occnc.com> To: "Dacheng Zhang(Dacheng)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 31 Mar 2011 09:31:39 -0000." Date: Thu, 31 Mar 2011 07:54:48 -0400 Sender: curtis@occnc.com X-Mailman-Approved-At: Thu, 31 Mar 2011 05:35:38 -0700 Cc: "ospf@ietf.org" , "karp@ietf.org" , "curtis@occnc.com" Subject: Re: [karp] draft-bhatia-karp-ospf-ip-layer-protection-03.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com 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, 31 Mar 2011 11:54:28 -0000 In message "Dacheng Zhang(Dacheng)" writes: > > >>It would be better to exchange a session key rather than just a > >>session ID. The reason to do this is so as not to use the same > >>session key over a long period of time and to use the shared or > >>public/private keys infrequently to provide very little data on which > >>to try to reverse engineer the keys. > > This draft assumes there is no automatic key management system > provided. If there is a auto KMP, challenge/response solution will not > be needed. Do you suggest that we should integrate a key negotiation > process in OSPF? This is about a session key. The session key is determined through an exchange that makes use of a shared or public/private key. OSPF has had a clear text password for decades and better authentication as time goes on that didn't put the key (password) in the clear. A shared key already exists so now new key management is being suggested. Curtis From gregory.ietf@gmail.com Thu Mar 31 08:44:57 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28743A6B0E for ; Thu, 31 Mar 2011 08:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.541 X-Spam-Level: X-Spam-Status: No, score=-103.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al-uwL6s-XHm for ; Thu, 31 Mar 2011 08:44:56 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id C51DA3A690D for ; Thu, 31 Mar 2011 08:44:56 -0700 (PDT) Received: by iye19 with SMTP id 19so2922451iye.31 for ; Thu, 31 Mar 2011 08:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=JSSnXITCwMYmN8DOSIcvGiMpQGW07D3gzemw2MMZ3AQ=; b=p3kJM5XUolalDyEG6x5ZTeCd09dWpzUVnFcR5iuBoJj4LYgKfVBjTthKBTz3opk0s4 tbDuRajcexPiphCeJTzOEQQLZhxseWAXcZ+DUbhQCMaznwDzS+XTYzrvCnzGLoIvATRV FQlUSgWOJ7xED14YVdncB8ZUAEXt7hlpVryJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sHkJFzIlrvO0aJYDzLiwP5KTXKcCCnHGQzFSWhTqnAj9yxNRK24/BVVBMgjHPwbtkN fxrFQyl0gI9ViAI1Ke72Bw+I7vHRTT0DTOnVxAXeQFkEZ256Oqojot6vppjHMm8LuiUG 5vS0mRDICGW14fY0s6t3H0oKyWq9sXNeK/4ME= MIME-Version: 1.0 Received: by 10.231.3.76 with SMTP id 12mr2685318ibm.166.1301586396382; Thu, 31 Mar 2011 08:46:36 -0700 (PDT) Received: by 10.231.66.18 with HTTP; Thu, 31 Mar 2011 08:46:36 -0700 (PDT) Date: Thu, 31 Mar 2011 08:46:36 -0700 Message-ID: From: Gregory Lebovitz To: karp@ietf.org Content-Type: multipart/alternative; boundary=000325560732cd0833049fc932f5 Subject: [karp] WebEx for Friday X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 15:44:57 -0000 --000325560732cd0833049fc932f5 Content-Type: text/plain; charset=ISO-8859-1 Hey team, Is there anyway to agree to use WebEx (or some other slide/screen sharing thing) for Friday's KARP session? Being remote this whole week I have found that having the slides projected over WebEx (or other) is a VERY helpful element for us remote folks to keep up, as it lets us see exactly what others are seeing when they are seeing it. There is too much error and delay in depending on a jabber hints. Let me know if that would be possible. Thanks much, Gregory -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --000325560732cd0833049fc932f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey team,
Is there anyway to agree to use WebEx (or some other slide/sc= reen sharing thing) for Friday's KARP session? Being remote this whole = week I have found that having the slides projected over WebEx (or other) is= a VERY helpful element for us remote folks to keep up, as it lets us see e= xactly what others are seeing when they are seeing it. There is too much er= ror and delay in depending on a jabber hints.

Let me know if that would be possible. Thanks much,
Gregory

--
----
IETF related email from<= br>Gregory M. Lebovitz
Juniper Networks
--000325560732cd0833049fc932f5-- From turners@ieca.com Thu Mar 31 09:07:31 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10BBD28C135 for ; Thu, 31 Mar 2011 09:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5aKQKne2BIn for ; Thu, 31 Mar 2011 09:07:30 -0700 (PDT) Received: from nm10-vm0.bullet.mail.ac4.yahoo.com (nm10-vm0.bullet.mail.ac4.yahoo.com [98.139.53.194]) by core3.amsl.com (Postfix) with SMTP id ACC0228C12B for ; Thu, 31 Mar 2011 09:07:29 -0700 (PDT) Received: from [98.139.52.196] by nm10.bullet.mail.ac4.yahoo.com with NNFMP; 31 Mar 2011 16:09:06 -0000 Received: from [98.139.52.138] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 31 Mar 2011 16:09:06 -0000 Received: from [127.0.0.1] by omp1021.mail.ac4.yahoo.com with NNFMP; 31 Mar 2011 16:09:06 -0000 X-Yahoo-Newman-Id: 859946.58515.bm@omp1021.mail.ac4.yahoo.com Received: (qmail 80898 invoked from network); 31 Mar 2011 16:09:06 -0000 Received: from dhcp-45e5.meeting.ietf.org (turners@198.180.150.234 with plain) by smtp113.biz.mail.re2.yahoo.com with SMTP; 31 Mar 2011 09:09:06 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: F1lVEGcVM1mutkxsRhXQ4L5nKY7dJBgC5PnbcwP.SKYvLrl Kax2q7zhG8gvHYPrrwW8qKPne2dzvjr1_jEBYymBQGMgny.7FiS_v3VzrZmB uW2UkyCb1LuF9TejjLSH4j5G5fu035sTwCdKSRJ8WihhwxobwQjjIEUJINpq .3rtvvolnq_6Jdd5SHakozJMFtoQijOFqpluwJWLj_nS_rJywNo9Rh.jAyaa 5rBwcXwmTcUnfnycXIFtpAM.MfEdG7Bz2sOhHgF7er9PPOuv43TWfzVHoLvc iUfMBgWdFi1ppE7cGQxmVpsY4cbej5y_qW6HmF7JUKWDzoJbjeVPMfHyRcMI Yp9xL39SZ4gtR X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D94A721.4050308@ieca.com> Date: Thu, 31 Mar 2011 18:09:05 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 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 Cc: karp@ietf.org Subject: Re: [karp] WebEx for Friday X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 16:07:31 -0000 It depends on what the room request included. Not sure what was requested. spt On 3/31/11 5:46 PM, Gregory Lebovitz wrote: > Hey team, > Is there anyway to agree to use WebEx (or some other slide/screen > sharing thing) for Friday's KARP session? Being remote this whole week I > have found that having the slides projected over WebEx (or other) is a > VERY helpful element for us remote folks to keep up, as it lets us see > exactly what others are seeing when they are seeing it. There is too > much error and delay in depending on a jabber hints. > > Let me know if that would be possible. Thanks much, > Gregory > > -- > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks > > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From gregory.ietf@gmail.com Thu Mar 31 17:56:43 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2FA83A6AD2 for ; Thu, 31 Mar 2011 17:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.56 X-Spam-Level: X-Spam-Status: No, score=-103.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPeG8Lx-KhRD for ; Thu, 31 Mar 2011 17:56:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 48E0F3A6AD0 for ; Thu, 31 Mar 2011 17:56:41 -0700 (PDT) Received: by iye19 with SMTP id 19so3418769iye.31 for ; Thu, 31 Mar 2011 17:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=tmnmHxf2U9WZ+eDzNPF8NhhG/xUC6wIXs9fSXdc03dU=; b=fZFSEGKLf2Xt3Vr/T5lKEOAbWdD9iGYOZjHaEsNH5wGWh2IaxRVl2+YcsFaXoRUNBq W8c4T7aArqIVLB4z+RD99+z/9ByRDRfBfVgp2m+LeeIRoWEkzXJSRlf//qfEPJzKTN2d z0nMSsYmay1tEbGSrdbcKJrlvWemHvcGPStOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Z0EfpNhaWaMngsF+P9PWKtXderW/cYS1jC1FlQsP3r+9hvddCO4CA23gkIqPSXDKIL O2PC1iv8BsnHKI5Bj3tTdtWOYgwtfZQSjwbGjc4fO4U0yp1KLCwumeH50kZI1dRMw8Co ZL/AdmhjeH6vZNm97gxPreet7k/ovNObp5bu0= MIME-Version: 1.0 Received: by 10.231.55.90 with SMTP id t26mr1967800ibg.116.1301619501112; Thu, 31 Mar 2011 17:58:21 -0700 (PDT) Received: by 10.231.66.18 with HTTP; Thu, 31 Mar 2011 17:58:21 -0700 (PDT) Date: Thu, 31 Mar 2011 17:58:21 -0700 Message-ID: From: Gregory Lebovitz To: karp@ietf.org, "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=000e0cd5f0d4ff1d18049fd0e7ea Subject: [karp] Review of design-guide-02 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 00:56:43 -0000 --000e0cd5f0d4ff1d18049fd0e7ea Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Karp'ies, Below you will see mostly small editorial nits. However, a few more substantive comments exist and should be addressed before moving to AD approval. In each case I have proposed new text. If there are no issues, Manav and I will edit the document per the suggestions below. I'll "see you" remotely in in a few hours at the session. - Gregory. =3D=3D=3D=3D=3D=3D=3D=3D Comments on karp-design-guide-02 Gregory Lebovitz 2011.03.30 "Abstract -- snip -- This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. " -- snip -- Is this last sentence true of this document? I think this is text rot from earlier versions of the document where the framework was also included in the body. I think it ought to be removed Suggested new text: "In particular, it categorizes existing routing protocols into logical groups for analysis and describes a process by which design teams are to review and work on updating those routing protocols, including security considerations. One specific design consideration is the for the future existence of an automated Key Management Protocol." 3.1, para 3 "Many routers have the ability to be remotely managed over the SSH [RFC4252] and [RFC4253]." New: =85 managed over SSH=85 "As such, they will also have the ability to generate and store an asymmetric key pair, because this is the commonly used method that users authenticate the SSH service when connecting to the router for management sessions." Awkward wording. New: Therefore, one can be sure these routers have the ability to generate and store an asymmetric key pair, because that capability is in use today for the ssh authentication. 3.1 para 4 s/Once asymmetric key pair/Once an asymmetric key pair/ s/for the identity proof/for its identity proof/ 3.2 title s/Keys Life Cycle/Keys' Life Cycle/ para 1 - s/using the key chains/using key chains/ add after "=85 leaves the company.": In the case of a terminated administrator, the security properties of on= e key are the same as those of a key chain. 4.1 para 1 - reads very awkwardly, and shortcuts things explained much more clearly a few paragraphs later. Remove the text explaining the separation o= f KMP from Routing Protocol, and leave it for point 2 a few paragraphs later. Re-write as: The authentication mechanism overhaul for any base routing protocol will b= e accomplished in two phases. Phase one will address the manual key managemen= t mechanism already in existence for the protocol, updating it to support modern cryptographic practices. Phase two will then provide the automated key management protocol and specifications for how the base protocol will use it. In this process we will crawl, walk, and then run. We will deliver incremental improvements in the security of these authentication mechanisms to the operators so that the changes are readily deployable. para 2: s/In other words, simplicity and deployability are keys to success./Simplicity and deployability are keys to success./ in the paragraph starting with "The framework=85" we reference the ietf-karp-framework document, which the ADs and Chairs want killed. So we need to strike it here. Instead, summarize with this text: It is useful to cleanly separate the key management protocol from the routing transport subsystem. The routing transport subsystem will be oblivious (for the most part) to how the keys are derived, exchanged, and acquired, and care only that a key and usage parameters are available to it= . For example, a routing protocol implementation could have a configuration switch that makes a request/call to a separate security module, asking for the "KARP parameters." Being separate, this security module could be writte= n and maintained by different developers, perhaps even a security team. The KMP module could also potentially be leveraged by other routing protocols. Of course these are implementation details; the example is offered merely t= o fill out the vision of a framework where a routing protocol and KMP are separate, but working together within the system. 4.2 Characterize the RP s/Does it needs significant/Does it need significant/ Define Optimal State s/usage and format to contain to modern/usage and format to contain modern/ Gap Analysis s/to its optimal state/to its optimal state for Phase 1/ KMP Analysis s/List the requirements that this Routing Protocol has for being able to be use in conjunctions with a KMP. Define the optimal state and check how easily it can be decoupled with the KMP./List the requirements for using this Routing Protocol in conjunctions with a KMP. Define the optimal state, keeping in mind the architectural goal that the routing protocol be decoupled from the KMP./ Define, Assign, Design new text, in light of the fact that we don't have a framework document anymore: =85These will be the attributes that the Routing Protocol and KMP will n= eed to trade in order to bootstrap the session keys to the Routing Protocol. [delete last paragraph that was in this section] 5. OSPF=85 s/peering messages includes OSPF/peering messages include OSPF/ 6. Gap Analysis para 4: re-write paragraph as follows, for read-ability: When doing the gap analysis the team must first identify the elements of each routing protocol to protect. In the case of protocols riding directly atop IP, consider if the IP header and the protocol headers ought to be protected. For those that sit atop TCP, consider if both the TCP header and the protocol payload ough= t to be covered by the authentication operation. There is value in protecting the IP header and the TCP header if the routing protocols rely on these headers (for example, for identifying the neighbor that originated the packet). para 5: s/Then there will be a set of Cryptography requirements that we might want to look at./Next, the team will consider cryptographic requirements./ s/MUST be at least on/MUST be at least one/ delete: The design teams should look for this for the protocol that they are working on. para 8: s/so that it does not get influenced by packets loss and reordering./so that the exchange is not negatively impacted by packet loss or re-ordering./ para 9: s/that their protocols authentication/that their protocol's authentication/ para 10: this statement is unclear. What does it mean to "affect the functioning of the routing protocol"? The example given doesn't help the reader to make that definition. Pls try and explain it better here, on email, and then we can figure out text to support it. 2nd-to-last para of 6: s/This means that the designers must work on this aspect of authentication mechanism for the routing protocol that they are working on./Design teams must address the need for incremental deployment./ That sentence will not be possible in some cases. What's more important is that implementations can run both the old and the new in parallel, and have a security policy to handle the transition case. Suggested new text: As such, the new mechanisms must either be backward compatible in the message formatting, transmission and processing of routing information, or implementations must be instructed to support running both the old and the new mechanisms simultaneously with local security policy to define when one= , the other, or both are allowed, and in what preference. Sect 7 7.1 para 2: s/The burden for doing so is understandable much higher/The burden for using unique keys per pair of peers is understandably higher/ para 3, last sentence: s/intra-connection replay protection./intra-connection replay protection will also be achieved./ 7.4 para 8: s/The desired end goal for KARP WG is develop a strong peer-to- peer KMP as an Out-of-and external Key Management protocol is out of scope./The desired end goal for KARP WG is develop a strong peer-to-peer KMP. An Out-of-Band external Key Management protocol is out of scope./ para 9: s/inside the protocol itself./inside the routing protocol itself./ --=20 ---- IETF related email from Gregory M. Lebovitz Juniper Networks --000e0cd5f0d4ff1d18049fd0e7ea Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Karp&#= 39;ies,


Below you will see mostly small editorial nits. However, a few more substan= tive comments exist and should be addressed before moving to AD approval. I= n each case I have proposed new text. If there are no issues, Manav and I w= ill edit the document per the suggestions below.=A0


I= 9;ll "see you" remotely in in a few hours at the session.


=3D=3D=3D=3D=3D=3D=3D=3D

Comments on = karp-design-guide-02

Gregory Lebovitz

2011.03.30


=A0"= ;Abstract


=A0=A0 = =A0 -- snip --

=A0 =A0 = =A0 This document is one of a series concerned with defining a

=A0 =A0 = =A0 roadmap of protocol specification work for the use of modern

=A0 =A0 = =A0 cryptographic mechanisms and algorithms for message

=A0 =A0 = =A0 authentication in routing protocols.=A0 In particular, it defines

=A0 =A0 = =A0 the framework for a key management protocol that may be used to

=A0 =A0 = =A0 create and manage session keys for message authentication and

=A0 =A0 = =A0 integrity.=A0 "

=A0 =A0 = -- snip --


Is this = last sentence true of this document? I think this is text rot from earlier = versions of the document where the framework was also included in the body.= I think it ought to be removed


Suggeste= d new text:


"In= particular, it categorizes existing routing protocols into logical groups = for analysis and describes a process by which design teams are to review an= d work on updating those routing protocols, including security consideratio= ns. One specific design consideration is the for the future existence of an= automated Key Management Protocol."




3.1, par= a 3

"Ma= ny routers have the ability to be remotely managed over the

=A0 =A0 = =A0 SSH [RFC4252] and [RFC4253]."


New: =A0= =85 managed over SSH=85


=A0"= ;As such, they will also have the

=A0 =A0 = =A0 ability to generate and store an asymmetric key pair, because

=A0 =A0 = =A0 this is the commonly used method that users authenticate the

=A0 =A0 = =A0 SSH service when connecting to the router for management

=A0 =A0 = =A0 sessions."


Awkward = wording. New:

=A0There= fore, one can be sure these routers have the ability to generate and store = an asymmetric key pair, because that capability is in use today for the ssh= authentication.


3.1 para= 4=A0

=A0s/Onc= e asymmetric key pair/Once an asymmetric key pair/

=A0s/for= the identity proof/for its identity proof/


3.2 titl= e s/Keys Life Cycle/Keys' Life Cycle/

=A0para = 1 - s/using the key chains/using key chains/

=A0add a= fter "=85 leaves the company.":

=A0=A0 I= n the case of a terminated administrator, the security properties of one ke= y are the same as those of a key chain.


4.1 para= 1 - reads very awkwardly, and shortcuts things explained much more clearly= a few paragraphs later. Remove the text explaining the separation of KMP f= rom Routing Protocol, and leave it for point 2 a few paragraphs later. Re-w= rite as:


=A0The a= uthentication mechanism overhaul for any base routing protocol will be acco= mplished in two phases. Phase one will address the manual key management me= chanism already in existence for the protocol, updating it to support moder= n cryptographic practices. Phase two will then provide the automated key ma= nagement protocol and specifications for how the base protocol will use it.= In this process we will crawl, walk, and then run. We will deliver increme= ntal improvements in the security of these authentication mechanisms to the= operators so that the changes are readily deployable.=A0


para 2: = s/In other words, simplicity and deployability are keys to success./Simplic= ity and deployability are keys to success./


in the p= aragraph starting with "The framework=85" we reference the ietf-k= arp-framework document, which the ADs and Chairs want killed. So we need to= strike it here. Instead, summarize with this text:


It is us= eful to cleanly separate the key management protocol from the routing trans= port subsystem. The routing transport subsystem will be oblivious (for the = most part) to how the keys are derived, exchanged, and acquired, and care o= nly that a key and usage parameters are available to it. For example, a rou= ting protocol implementation could have a configuration switch that makes a= request/call to a separate security module, asking for the "KARP para= meters." Being separate, this security module could be written and mai= ntained by different developers, perhaps even a security team. The KMP modu= le could also potentially be leveraged by other routing protocols. Of cours= e these are implementation details; the example is offered merely to fill o= ut the vision of a framework where a routing protocol and KMP are separate,= but working together within the system.=A0


4.2

=A0Chara= cterize the RP

=A0 s/Do= es it needs significant/Does it need significant/


=A0Defin= e Optimal State

=A0 s/us= age and format to contain to modern/usage and format to contain modern/


=A0Gap A= nalysis

=A0 s/to= its optimal state/to its optimal state for Phase 1/


=A0KMP A= nalysis

=A0 s/Li= st the requirements that this Routing Protocol has for being able to be use= in conjunctions with a KMP. Define the optimal state and check how easily = it can be decoupled with the KMP./List the requirements for using this Rout= ing Protocol in conjunctions with a KMP. Define the optimal state, keeping = in mind the architectural goal that the routing protocol be decoupled from = the KMP./

=A0

=A0Defin= e, Assign, Design

=A0 new = text, in light of the fact that we don't have a framework document anym= ore:

=A0=A0 = =85These will be the attributes that the Routing Protocol and KMP will need= to trade in order to bootstrap the session keys to the Routing Protocol. [= delete last paragraph that was in this section]


5. OSPF= =85

=A0 s/pe= ering messages includes OSPF/peering messages include OSPF/

=A0

6. Gap A= nalysis

=A0 para= 4: re-write paragraph as follows, for read-ability:

When doi= ng the gap analysis the team must first identify the elements

=A0 =A0 = =A0 of each routing protocol to protect. In the case of

=A0 =A0 = =A0 protocols riding directly atop IP, consider if the IP

=A0 =A0 = =A0 header and the protocol headers ought to be protected. For those that s= it atop TCP, consider if both the TCP header and the protocol payload ought= to be covered by the authentication operation.

=A0 =A0 = =A0 There is value in protecting the IP header and the TCP

=A0 =A0 = =A0 header if the routing protocols rely on these headers (for example, for= identifying the neighbor that

=A0 =A0 = =A0 originated the packet).


=A0para = 5:=A0

=A0=A0 s= /Then there will be a set of Cryptography requirements that we might want t= o look at./Next, the team will consider cryptographic requirements./

=A0=A0 s= /MUST be at least on/MUST be at least one/

=A0=A0 d= elete: The design teams should look for this for the protocol

=A0 =A0 = =A0 that they are working on.=A0

=A0 =A0

=A0para = 8: s/so that it does not get influenced by packets loss and reordering./so = that the exchange is not negatively impacted by packet loss or re-ordering.= /


=A0para = 9: s/that their protocols authentication/that their protocol's authenti= cation/=A0


=A0para = 10: this statement is unclear. What does it mean to "affect the functi= oning of the routing protocol"? The example given doesn't help the= reader to make that definition. Pls try and explain it better here, on ema= il, and then we can figure out text to support it.


2nd-to-l= ast para of 6:=A0

=A0s/Thi= s means that the designers must work

=A0 =A0 = =A0 on this aspect of authentication mechanism for the routing

=A0 =A0 = =A0 protocol that they are working on./Design teams must address the need f= or incremental deployment./


=A0=A0 T= hat sentence will not be possible in some cases. What's more important = is that implementations can run both the old and the new in parallel, and h= ave a security policy to handle the transition case. Suggested new text:

=A0=A0 A= s such, the new mechanisms must either be backward compatible in the messag= e formatting, transmission and processing of routing information, or implem= entations must be instructed to support running both the old and the new me= chanisms simultaneously with local security policy to define when one, the = other, or both are allowed, and in what preference.


Sect 7

7.1

=A0para = 2: s/The burden for doing so is understandable much higher/The burden for u= sing unique keys per pair of peers is understandably higher/


=A0para = 3, last sentence: s/intra-connection replay protection./intra-connection re= play protection will also be achieved./


7.4

para 8: = s/The desired end goal for KARP WG is develop a strong peer-to-

=A0 =A0 = =A0 peer KMP as an Out-of-and external Key Management protocol is

=A0 =A0 = =A0 out of scope./The desired end goal for KARP WG is develop a strong peer= -to-peer KMP. An Out-of-Band external Key Management protocol is

=A0 =A0 = =A0 out of scope./


para 9: = s/inside the protocol itself./inside the routing protocol itself./

=
<eof>
--
----
IETF related email from
Gregory = M. Lebovitz
Juniper Networks
--000e0cd5f0d4ff1d18049fd0e7ea-- From gregory.ietf@gmail.com Thu Mar 31 23:57:28 2011 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9DC3A6B32 for ; Thu, 31 Mar 2011 23:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.27 X-Spam-Level: X-Spam-Status: No, score=-103.27 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR7G2e1FPNh4 for ; Thu, 31 Mar 2011 23:57:26 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 10CF73A6B04 for ; Thu, 31 Mar 2011 23:57:26 -0700 (PDT) Received: by iwn39 with SMTP id 39so3682970iwn.31 for ; Thu, 31 Mar 2011 23:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=8ZKOxTBACMDDUNm/M7JvrIJK1uKv6xNBjeCpD2thnG8=; b=rbpIN0MJr7mjMKNitH35ld6o+bDCa3nrtzAdTJuutNTNsc1bkyS/1EMqYl8fqN2uWi LGJN8Vc3g1vRdmpDVvQKJusbXeA6mxbYMfPJsNuOb4uSuaT1WWPWrFy4kE/fnrxGzMY5 MkcVAkjMJ5ex9fa1JrgJOdT/HTyUt2Rs68nIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=HIfAns7/pXUDm7JwT9iR2oHtASnmUHB85Wort/krb5HThBIzN9ftD3e1TX/KHAPYfB Fg45C6CpBSJybH3cVsxyG+AfpYy+CcC8YfwIljc/uVBaBP9pqqwOteRVGu3rISaNMj3W JKutubTeyqo7RSfoi5bCod3GRzOrLxE5HFrYk= MIME-Version: 1.0 Received: by 10.42.37.199 with SMTP id z7mr13898icd.110.1301640917599; Thu, 31 Mar 2011 23:55:17 -0700 (PDT) Received: by 10.231.66.18 with HTTP; Thu, 31 Mar 2011 23:55:17 -0700 (PDT) Date: Thu, 31 Mar 2011 23:55:17 -0700 Message-ID: From: Gregory Lebovitz To: Sam Hartman , Dacheng Zhang Content-Type: multipart/alternative; boundary=90e6ba6e8d4084c769049fd5e4aa Cc: karp@ietf.org Subject: [karp] Review of ...karp-mrkmp-01 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 06:57:28 -0000 --90e6ba6e8d4084c769049fd5e4aa Content-Type: text/plain; charset=ISO-8859-1 eview-gregory-draft-hartman-karp-mrkmp-01 Review by Gregory Lebovitz 2011-03-31 This review covers Abstract, sections 1, 2, 7, 8, (a review of sections 3 & 9 will be sent later, in a few days. Sections 4-6 will be reviewed once filled out) Suggest we simplify the name to MaRK, but still call it "Multicast Router Key Management Protocol". Just a marketing thing. (You'll notice "IKE" did a lot better than "ISAKMP"). To "test it out" I refer to mrkmp as "MaRK" through the rest of the review. Let me know if you all like it. 1.1 - time for beginning to fill this section out? 1.3 - since we are talking about the use of IKEv2, where Phase 1 and Phase 2 have been replaced by "Parent SA" and "Child SA", ought we conform to that terminology? Do we talk anywhere in this doc about scope of this design in the context of the overall framework (which has been pretty much killed now)? Specifically, this spec is to be used on a single broadcast domain / link / NBMA segment. Each such segment will have it's own MaRK going on. A segment can be as small as two routers, or as large as N routers, such that the two-router case is simply a specific usage of the same mechanism, and thus solves the multicasting routing protocols case as well as the unicasting protocols' case. And we'll need to talk about, but not solve, the case of changing keys on GCKS's across a large network, where there may be hundreds (thousands?) of GCKS's. We'll want to do this so that people get the context clear. We don't want to rathole on it now, though. I volunteer to author the text for a section that accomplishes my last two paragraphs. 2.1 Peer Key Mgmt Key: point out that this is pair-wise unique? KEK - is the "message encrypted in a previous KEK" the IKEv2 REKEY message exchange? If so, can we simply say that? Protocol Master Key - add: "This key is distinguished from the 'transport key' (see next) in that this Protocol Master Key may be used in a cryptographic operation in order to derive a specific transport key. transport key: s/challenging with this architecture/challenging with this design/ I really like the way you've clearly and succinctly laid out the difference between the different key types. A graphic would do WONDERS for helping people to quickly grasp the differences between these keys. Perhaps a table would also help. Maybe something where the rows are the types of keys and the columns are thinks like "KMP usage vs RP usage," "bootstrapping vs traffic," "Group vs Pair-wise vs Both," and "other" for comment or clarification. 2.1.1 - "provide both integrity and confidentiality" - throughout the document it looks like you include authentication in the word "integrity"? Maybe we should explicitly state this upfront, and explain why? Do we care about non-repudiation? ?? expiration time measure in clicks from when set? Absolute clock time? "group members need to perform a new initial exchange to the GCKS" This is a matter of local policy configuration. Perhaps we ought to say it this way: "When a KEK is retired or expires without being replaced by a new KEK announced in the old KEK, the group members delete that KEK. Unless local policy configuration dictates otherwise, the group member will perform a new initial exchange to the GCKS in order to establish a new KEK." The way described in the text I offered is a little more IKEv2-like. 2.1.2 - in the case of separate protocol master key and traffic key, where you propose a nonce exchange, is the nonce exchange protected? After a lot of work on IKE, IKEv2, SSH and TCP-AO, I STRONGLY favor the second model, the separation of proto master key and traffic key. 2.2 - "As a consequence of such cases, an individual GCKS electing solution within MRKMP is preferable." For the sake of testing the hypothesis, I'd like to see someone try to come up with a counter argument to this and see if it is at all convincing. I think I agree with your stated hypothesis, but I'd like others closer to routing protocol development to try it. We may also want to describe the chicken and egg issue here: we are trying to elect someone to be the GCKS for the purpose of authentication of each peer, but we can't do that until we authenticate each peer. And then we would want to discuss at a high level how the design addresses that. If you think this would be helpful to address in the overview here, then I could write text to accomplish it. 2.3 "Unicast MRKMP P messages" - drop the "P" ? - again, here you use "integrity" to also include per-packet "authentication". See my comment above. - "While routing security does not typically require confidentiality, the key management protocol does because keys are exchanged and these must be protected." - great sentence, and well placed. I could see a lot of non-security people being confused without this point. Good job!! "Other mechanisms may be added as a future extension." why wouldn't we add in the use of simple asymmetric keying mechanisms here, like Self-signed cert, or raw asymetric key? As you may recall, I'm very in favor of the use of self-signed certs in this application, since the operators all use them already for SSH'ing to the boxes. It's really no more complex than a strong PSK, operationally, but provides far more value. I propose we add at least self-signed cert with manual fingerprint verification to the list in the first spec. 2.4 "XXX we need to discuss group naming--if MRKMP is limited to a subnet this may be as simple as saying that initiator wants to join the OSPF group or the IS-IS group." why wouldn't we use a group identifier? This would provide us with extensibility, prevent ambiguous situations in large routers with many interfaces in adjacent segments/links, etc. My gut tells me having an explicit group identifier is just more clean. I would guess that only 4 bits would be necessary, but we could make it 8 bits, just in case. "Once membership in a group is established, resources are not required to maintain the unicast association with the GCKS." In testing this hypothesis I came up with one reason we may want it: liveness detection. We would want a liveness check to be auth'd / integrity checked per packet. I could see this being very important to ops and management. Thoughts? "A member of a group can also use the unicast exchange to request a GCKS to change the protocol master key because that group has exhausted its available sequence space." wouldn't the GCKS itself already know if / when the available sequence space had been exhausted? If so, wouldn't it simply init the new key process well prior to the exhaustion? I really like how the document is organized with an overview of the major parts, so one can see the whole protocol in context more quickly, and then deep dives into each part in more detail. Well done!! 7. 7.1 7.2 - given multiple senders on (potentially) broadcast domain, how do we avoid sequence number stomping, multiple senders issuing packets with the same sequence number at the same time? - maybe we should use a concatenation of sender + seq# ? Or maybe I missed something earlier in the draft that explains this? Other things to add to 7: 7.4 Example of a key change, walk through it for a case with 4 peers or so. 7.5 - Ares for monitoring and management - brainstorm what sorts of items will be critical for actual operation. 7.6 - peer liveness detection 7.7 - example of a reboot case. For a GCKS. For a non-GCKS peer. 7.8 - administrative stand-down of a GCKS. Do we have a state where a GCKS can be administratively set to "not participating" while maintenance is done, without having to change it's config? Such that once maintenance is complete, it will change state back to becoming GCKS preemptively. This is very helpful for real life operations. 8. 8.2 This may lead to a lot of flapping. Not sure how good of an idea this is. We should start some threads just on this topic to explore/test it some more. 8.3 - same with interface link down, BFD state down, etc. Possible new section: UI Hints - it would be nice if all the vendors implementations treated the config some what similarly for MaRK. For example, do you show a whole separate MaRK config section, and leave it loosely linked in the UI to the routing protocols? Or do you bake the MaRK config into the routing protocol UI area? To avoid operator confusion, and assist with deployment ease between pkt interoperable implementations, we ought to give some hints around UI in this way. - we'll also want to identify profiles for crypto suites and lifetime settings, etc. to make config MUCH easier for operators. This is a working group operation and priorities question: How much have we tested MaRK to see if it addresses everything we need for a KMP for BGP? I ask this because we've all agreed previously that: - KMP for BGP is the Internet security highest priority for KMP work - we wanted to try to make a mcast capable KMP fit for OSPF and ISIS, and then use the two-peer case of it for BGP to see if we could in fact use one? At what point are we certain enough of the validity of something like MaRK for the mast case that we can slow efforts there and shift to validation/verification for BGP? -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --90e6ba6e8d4084c769049fd5e4aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

eview-= gregory-draft-hartman-karp-mrkmp-01


Review= by Gregory Lebovitz

2011-0= 3-31

This r= eview covers Abstract, sections 1, 2, 7, 8,

(a rev= iew of sections 3 & 9 will be sent later, in a few days. Sections 4-6 w= ill be reviewed once filled out)


Sugges= t we simplify the name to MaRK, but still call it "Multicast Router Ke= y Management Protocol". Just a marketing thing. (You'll notice &qu= ot;IKE" did a lot better than "ISAKMP"). To "test it ou= t" I refer to mrkmp as "MaRK" through the rest of the review= . Let me know if you all like it.


1.1 - = time for beginning to fill this section out?


1.3 - = since we are talking about the use of IKEv2, where Phase 1 and Phase 2 have= been replaced by "Parent SA" and "Child SA", ought we = conform to that terminology?


Do we = talk anywhere in this doc about scope of this design in the context of the = overall framework (which has been pretty much killed now)? Specifically, th= is spec is to be used on a single broadcast domain / link / NBMA segment. E= ach such segment will have it's own MaRK going on. A segment can be as = small as two routers, or as large as N routers, such that the two-router ca= se is simply a specific usage of the same mechanism, and thus solves the mu= lticasting routing protocols case as well as the unicasting protocols' = case.


And we= 'll need to talk about, but not solve, the case of changing keys on GCK= S's across a large network, where there may be hundreds (thousands?) of= GCKS's.=A0 We'll want to do this so that people get the context cl= ear. We don't want to rathole on it now, though.


I volu= nteer to author the text for a section that accomplishes my last two paragr= aphs.


2.1 Pe= er Key Mgmt Key: point out that this is pair-wise unique?

=A0 KE= K - is the "message encrypted in a previous KEK" the IKEv2 REKEY = message exchange? If so, can we simply say that?

=A0 Pr= otocol Master Key=A0 - add: "This key is distinguished from the 't= ransport key' (see next) in that this Protocol Master Key may be used i= n a cryptographic operation in order to derive a specific transport key.

=A0 tr= ansport key: s/challenging with this architecture/challenging with this des= ign/


=A0I r= eally like the way you've clearly and succinctly laid out the differenc= e between the different key types. A graphic would do WONDERS for helping p= eople to quickly grasp the differences between these keys. Perhaps a table = would also help. Maybe something where the rows are the types of keys and t= he columns are thinks like "KMP usage vs RP usage," "bootstr= apping vs traffic," "Group vs Pair-wise vs Both," and "= other" for comment or clarification.=A0


2.1.1 = - "provide both integrity and confidentiality" - throughout the d= ocument it looks like you include authentication in the word "integrit= y"? Maybe we should explicitly state this upfront, and explain why? Do= we care about non-repudiation?


?? exp= iration time measure in clicks from when set? Absolute clock time?


"group members need to perform a= new initial exchange to the GCKS"

This is = a matter of local policy configuration. Perhaps we ought to say it this way= :

=A0 &quo= t;When a KEK is retired or expires without being replaced by a new KEK anno= unced in the old KEK, the group members delete that KEK. Unless local polic= y configuration dictates otherwise, the group member will perform a new ini= tial exchange to the GCKS in order to establish a new KEK."

=A0 Th= e way described in the text I offered is a little more IKEv2-like.


2.1.2 = - in the case of separate protocol master key and traffic key, where you pr= opose a nonce exchange, is the nonce exchange protected?

=A0=A0= After a lot of work on IKE, IKEv2, SSH and TCP-AO, I STRONGLY favor the se= cond model, the separation of proto master key and traffic key.


2.2 - "As a consequence of such = cases, an individual GCKS electing solution within MRKMP is preferable.&quo= t;

For th= e sake of testing the hypothesis, I'd like to see someone try to come u= p with a counter argument to this and see if it is at all convincing. I thi= nk I agree with your stated hypothesis, but I'd like others closer to r= outing protocol development to try it.


We may= also want to describe the chicken and egg issue here:=A0 we are trying to = elect someone to be the GCKS for the purpose of authentication of each peer= , but we can't do that until we authenticate each peer. And then we wou= ld want to discuss at a high level how the design addresses that. If you th= ink this would be helpful to address in the overview here, then I could wri= te text to accomplish it.


2.3 &q= uot;Unicast MRKMP P messages"=A0 - drop the "P" ?

=A0 - = again, here you use "integrity" to also include per-packet "= authentication". See my comment above.

=A0- "While routing security doe= s not typically require confidentiality, the key management protocol does b= ecause keys are exchanged and these must be protected."=A0 - great sen= tence, and well placed. I could see a lot of non-security people being conf= used without this point. Good job!!


=A0"Other mechanisms may be adde= d as a future extension."

=A0 why = wouldn't we add in the use of simple asymmetric keying mechanisms here,= like Self-signed cert, or raw asymetric key? As you may recall, I'm ve= ry in favor of the use of self-signed certs in this application, since the = operators all use them already for SSH'ing to the boxes. It's reall= y no more complex than a strong PSK, operationally, but provides far more v= alue. I propose we add at least self-signed cert with manual fingerprint ve= rification to the list in the first spec.


2.4

=A0"= ;XXX we need to discuss group naming--if MRKMP is limited to a subnet this = may be as simple as saying that initiator wants to join the OSPF group or t= he IS-IS group."

=A0=A0

=A0 why = wouldn't we use a group identifier? This would provide us with extensib= ility, prevent ambiguous situations in large routers with many interfaces i= n adjacent segments/links, etc. My gut tells me having an explicit group id= entifier is just more clean. I would guess that only 4 bits would be necess= ary, but we could make it 8 bits, just in case.


"On= ce membership in a group is established, resources are not required to main= tain the unicast association with the GCKS."

=A0 In t= esting this hypothesis I came up with one reason we may want it:=A0 livenes= s detection. We would want a liveness check to be auth'd / integrity ch= ecked per packet. I could see this being very important to ops and manageme= nt. Thoughts?


"A = member of a group can also use the unicast exchange to request a GCKS to ch= ange the protocol master key because that group has exhausted its available= sequence space."

=A0 woul= dn't the GCKS itself already know if / when the available sequence spac= e had been exhausted? If so, wouldn't it simply init the new key proces= s well prior to the exhaustion?



I really= like how the document is organized with an overview of the major parts, so= one can see the whole protocol in context more quickly, and then deep dive= s into each part in more detail. Well done!!



7.

=A07.1


=A07.2 -= given multiple senders on (potentially) broadcast domain, how do we avoid = sequence number stomping, multiple senders issuing packets with the same se= quence number at the same time? - maybe we should use a concatenation of se= nder + seq# ? Or maybe I missed something earlier in the draft that explain= s this?


=A0Other= things to add to 7:

=A07.4= =A0 Example of a key change, walk through it for a case with 4 peers or so.=

=A07.5 -= Ares for monitoring and management - brainstorm what sorts of items will b= e critical for actual operation.=A0

=A07.6 -= peer liveness detection

=A07.7 -= example of a reboot case. For a GCKS. For a non-GCKS peer.

=A07.8 -= administrative stand-down of a GCKS. Do we have a state where a GCKS can b= e administratively set to "not participating" while maintenance i= s done, without having to change it's config? Such that once maintenanc= e is complete, it will change state back to becoming GCKS preemptively. Thi= s is very helpful for real life operations.


8.

=A08.2 T= his may lead to a lot of flapping. Not sure how good of an idea this is. We= should start some threads just on this topic to explore/test it some more.=

=A08.3 -= same with interface link down, BFD state down, etc.


Possible= new section: UI Hints

=A0- it = would be nice if all the vendors implementations treated the config some wh= at similarly for MaRK. For example, do you show a whole separate MaRK confi= g section, and leave it loosely linked in the UI to the routing protocols? = Or do you bake the MaRK config into the routing protocol UI area? To avoid = operator confusion, and assist with deployment ease between pkt interoperab= le implementations, we ought to give some hints around UI in this way.

=A0- we&= #39;ll also want to identify profiles for crypto suites and lifetime settin= gs, etc. to make config MUCH easier for operators.=A0


This is = a working group operation and priorities question: How much have we tested = MaRK to see if it addresses everything we need for a KMP for BGP? I ask thi= s because we've all agreed previously that:

=A0- KMP= for BGP is the Internet security highest priority for KMP work

=A0- we = wanted to try to make a mcast capable KMP fit for OSPF and ISIS, and then u= se the two-peer case of it for BGP to see if we could in fact use one?

At what = point are we certain enough of the validity of something like MaRK for the = mast case that we can slow efforts there and shift to validation/verificati= on for BGP?=A0

=A0=A0

<eo= f>


--
----
IETF related email from
Gregory M. Lebovitz<= br>Juniper Networks
--90e6ba6e8d4084c769049fd5e4aa--