From russ@cisco.com Fri Jan 7 12:36:09 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 E9CBE3A697E for ; Fri, 7 Jan 2011 12:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 mowtOaYN6GWx for ; Fri, 7 Jan 2011 12:36:08 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AEBCF3A6979 for ; Fri, 7 Jan 2011 12:36:08 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADsIJ01AZnwN/2dsb2JhbACkK3OjGJgEhUwEhGeGIoMe Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Jan 2011 20:38:15 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p07KcFWj009096 for ; Fri, 7 Jan 2011 20:38:15 GMT Message-ID: <4D2779C2.4090306@cisco.com> Date: Fri, 07 Jan 2011 15:38:26 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: karp@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [karp] Responses to Comments for 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: Fri, 07 Jan 2011 20:36:10 -0000 Y'all: In the mess of trying to get through the comments to this document, we split things up and somehow lost track of what has been responded to and what hasn't. I'm hoping Manral will post a new version for review, but I know there were two specific comments we didn't address, and I wanted to provide some information here in case others wanted to discuss these two. == In the section on brute force attacks, the document says: > While it is impossible to make brute force attacks on keys completely > unsuccessful, proper design can make such attacks much harder to > succeed. The comment was: > I don't agree that this is true in any practical sense. If your keys > are 256 bits long, then brute force attacks are effectively impossible. It seems to me that brute force attacks are always a matter of horsepower and algorithms. As the horsepower available in silicon increases, the possibility of a brute force attack increases with it. Clouds of computers (such as SETI) can bring a lot of horsepower online very quickly --so I don't think we should ever rule out caution in the space of key length, or using longer keys where possible. == == The draft says: > The authentication mechanism in the Routing Protocol MUST be > decoupled from the key management system used. It MUST be > obvious how the keying material was obtained, and the process > for obtaining the keying material MUST exist outside of the > Routing Protocol. This will allow for the various key > generation methods, like manual keys and KMPs, to be used with > the same Routing Protocol mechanism. The comment was: > I don't agree with this requirement, which precludes much of our effective security technology, such as, for instance, TLS. This is probably one of the most controversial areas on which we need to agree as a WG. My sense is that tying keying materials to the control plane protocols is a bad thing --something like a layering violation, in a sense. If we look at why layering is "good network hygiene," we find the reason is to split complexity from complexity and divide failure domains. Protocols that provide reachability information, either at layer 2 or layer 3, seem very complex to me (and this is probably where the disagreement lies --many people think these protocols are relatively easy to digest and manage, so they don't see the complexity I do), and the protocols and "stuff" that goes around key management appears to be very complex to me, as well. So my sense is that dividing the reachability control plane from the encryption control plane is a "good thing," likely to result in fewer poorly understood feedback loops, and fewer unintended consequences. I'm pretty strongly in favor of splitting these where possible, and making the API between as transparent as possible. But I'm willing to hear arguments to the contrary. == :-) Russ -- riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone Now, we never can annihilate a penalty. We can only divert it from the head of the man who has incurred it to the heads of others who have not incurred it. A vast amount of "social reform" consists in just this operation. -William Graham Sumner From hartmans@mit.edu Mon Jan 10 11:31: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 1125428C0EF for ; Mon, 10 Jan 2011 11:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=-1.069, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, 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 RcSv2omySCqj for ; Mon, 10 Jan 2011 11:30:59 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 404EE28B23E for ; Mon, 10 Jan 2011 11:30:59 -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 8A136200CC; Mon, 10 Jan 2011 14:31:39 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C98F84228; Mon, 10 Jan 2011 14:33:12 -0500 (EST) From: Sam Hartman To: Russ White References: <4D2779C2.4090306@cisco.com> Date: Mon, 10 Jan 2011 14:33:12 -0500 In-Reply-To: <4D2779C2.4090306@cisco.com> (Russ White's message of "Fri, 07 Jan 2011 15:38:26 -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] Responses to Comments for 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: Mon, 10 Jan 2011 19:31:00 -0000 >>>>> "Russ" == Russ White writes: Russ> So my sense is that dividing the reachability control plane Russ> from the encryption control plane is a "good thing," likely to Russ> result in fewer poorly understood feedback loops, and fewer Russ> unintended consequences. I'm pretty strongly in favor of Russ> splitting these where possible, and making the API between as Russ> transparent as possible. Russ> But I'm willing to hear arguments to the contrary. == Russ, I think there is consensus on the requirement currently in the document. I don't think the compelling arguments are about what the right thing to do is:m y personal opinion is that the requirement is not the best technical approach, but that this split is not nearly as bad of a thing as I at first thought it was when I started thinking about KARP. However people have made claims that those doing the implementation work in this space strongly prefer the split and that adopting a requirement for this split will make it more likely to succeed. I don't think that such a split is bad enough on a technical front that we should rule it out. So, if the split gets us implementations and the lack of a split gets us irrelevance, let's go with the requirement. So, my question to the WG as a whole is do we actually want to have another round of discussion on whether Russ's technical argument above is correct? Or are we willing to accept this requirement as a practical necessity? My personal opinion is that this requirement is not a technical issue and so having this as a technical discussion is not an effective strategy. I feel strongly that we should make forward progress and do not feel that strongly about whether this requirement should be present. That said, if people want to have the technical discussion I'm happy to join it on the list or in private. From michael_barnes@usa.net Mon Jan 10 14:52:40 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 612C73A67A6 for ; Mon, 10 Jan 2011 14:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.295 X-Spam-Level: X-Spam-Status: No, score=0.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_NUMERIC_HELO=2.067, 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 DlmuTVgPZmvG for ; Mon, 10 Jan 2011 14:52:39 -0800 (PST) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by core3.amsl.com (Postfix) with ESMTP id 871B63A672F for ; Mon, 10 Jan 2011 14:52:39 -0800 (PST) Received: from cmsout01.mbox.net (cmsout01-lo [127.0.0.1]) by cmsout01.mbox.net (Postfix) with ESMTP id 0D22F2AC9DD; Mon, 10 Jan 2011 22:54:54 +0000 (GMT) X-USANET-Received: from cmsout01.mbox.net [127.0.0.1] by cmsout01.mbox.net via mtad (C8.MAIN.3.71F) with ESMTP id 416PaJw3x8320M01; Mon, 10 Jan 2011 22:54:49 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from cmsapps02.cms.usa.net [165.212.11.138] by cmsout01.mbox.net via smtad (C8.MAIN.3.68M) with ESMTP id XID436PaJw3x1663X01; Mon, 10 Jan 2011 22:54:49 -0000 X-USANET-Source: 165.212.11.138 IN michael_barnes@usa.net cmsapps02.cms.usa.net X-USANET-MsgId: XID436PaJw3x1663X01 Received: from web01.cms.usa.net [165.212.8.201] by cmsapps02.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.71F) with ESMTP id 813PaJw3x8768M38; Mon, 10 Jan 2011 22:54:49 -0000 X-USANET-Auth: 165.212.8.201 AUTO michael_barnes@usa.net web01.cms.usa.net Received: from 128.107.114.137 [128.107.114.137] by web01.cms.usa.net (USANET web-mailer C8.MAIN.3.71Y); Mon, 10 Jan 2011 22:54:49 -0000 Date: Mon, 10 Jan 2011 14:54:49 -0800 From: "Michael Barnes" To: Sam Hartman , Russ White X-Mailer: USANET web-mailer (C8.MAIN.3.71Y) Mime-Version: 1.0 Message-ID: <554PaJw2x5680S01.1294700089@web01.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID813PaJw3x8768X38 Cc: karp@ietf.org Subject: Re: [karp] Responses to Comments for 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: Mon, 10 Jan 2011 22:52:40 -0000 Hi San & Russ, From: Sam Hartman To: Russ White Cc: karp@ietf.org > >>>>> "Russ" =3D=3D Russ White writes: > = > = > Russ> So my sense is that dividing the reachability control plane > Russ> from the encryption control plane is a "good thing," likely t= o > Russ> result in fewer poorly understood feedback loops, and fewer > Russ> unintended consequences. I'm pretty strongly in favor of > Russ> splitting these where possible, and making the API between as= > Russ> transparent as possible. > = > Russ> But I'm willing to hear arguments to the contrary. =3D=3D > = > Russ, I think there is consensus on the requirement currently in the > document. I don't think the compelling arguments are about what the > right thing to do is:m y personal opinion is that the requirement is no= t > the best technical approach, but that this split is not nearly as bad o= f > a thing as I at first thought it was when I started thinking about KARP= =2E > = > However people have made claims that those doing the implementation wor= k > in this space strongly prefer the split and that adopting a requirement= > for this split will make it more likely to succeed. I don't think that= > such a split is bad enough on a technical front that we should rule it > out. So, if the split gets us implementations and the lack of a split > gets us irrelevance, let's go with the requirement. > = > So, my question to the WG as a whole is do we actually want to have > another round of discussion on whether Russ's technical argument above > is correct? Or are we willing to accept this requirement as a practical= > necessity? My personal opinion is that this requirement is not a > technical issue and so having this as a technical discussion is not an > effective strategy. I feel strongly that we should make forward progres= s > and do not feel that strongly about whether this requirement should be > present. > = > That said, if people want to have the technical discussion I'm happy to= > join it on the list or in private. I thought there had already been a good discussion of this point and thou= ght it had been closed. I'm happy with the requirement as it is written. -Michael From glen.kent@gmail.com Tue Jan 11 16:53:59 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 02D123A6801 for ; Tue, 11 Jan 2011 16:53:59 -0800 (PST) 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.268, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 Es-HCEHYZFOj for ; Tue, 11 Jan 2011 16:53:58 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B42433A67EF for ; Tue, 11 Jan 2011 16:53:57 -0800 (PST) Received: by ewy8 with SMTP id 8so23625ewy.31 for ; Tue, 11 Jan 2011 16:56:15 -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=58NK5DtjfT6beoJ8U9+6wVcn9w47U59MKCShDKiR4ug=; b=rtbHjX5LS/qhvIKvC28rx40NZ3dNyNFs4aFKgVSO6QBq5v3OSkG9anhwfrte9SC8mj aqth23BqSLl9KVJTGhcPkvljeUeHz2LoLu/aT/mIHRyIboGE06DodUHdcundEOQEukK3 XrrN/ai+TZfSgZJ6Zgo999xxiR5iQXwuo+5m8= 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=XZJXfH/fvFIhfjzktH4PdQovKk7/BbXDVz/9i79Mr5J7RB3IR8TDDV3zXgzkLkIZd8 dYKXovGchXjgWCaF9NhdFqjcm7Zchh7YfoRfX9tdGc0gQx1bSFgIo2Drekb3pg11OxTu h/1a/7uMVZwiSplpjopqh7zQDxmDoMSd6zkhk= MIME-Version: 1.0 Received: by 10.14.53.75 with SMTP id f51mr222904eec.4.1294793775157; Tue, 11 Jan 2011 16:56:15 -0800 (PST) Received: by 10.14.125.146 with HTTP; Tue, 11 Jan 2011 16:56:15 -0800 (PST) In-Reply-To: <554PaJw2x5680S01.1294700089@web01.cms.usa.net> References: <554PaJw2x5680S01.1294700089@web01.cms.usa.net> Date: Wed, 12 Jan 2011 06:26:15 +0530 Message-ID: From: Glen Kent To: Michael Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: karp@ietf.org, Sam Hartman Subject: Re: [karp] Responses to Comments for 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, 12 Jan 2011 00:53:59 -0000 I agree and i would like it to remain the way it is in the threats-reqs document. We can come back to it later if we find that this decoupling is not possible or is highly unoptimal. Glen On Tue, Jan 11, 2011 at 4:24 AM, Michael Barnes wr= ote: > Hi San & Russ, > > From: Sam Hartman > To: Russ White Cc: karp@ietf.org > >> >>>>> "Russ" =3D=3D Russ White writes: >> >> >> =A0 =A0 Russ> So my sense is that dividing the reachability control plan= e >> =A0 =A0 Russ> from the encryption control plane is a "good thing," likel= y to >> =A0 =A0 Russ> result in fewer poorly understood feedback loops, and fewe= r >> =A0 =A0 Russ> unintended consequences. I'm pretty strongly in favor of >> =A0 =A0 Russ> splitting these where possible, and making the API between= as >> =A0 =A0 Russ> transparent as possible. >> >> =A0 =A0 Russ> But I'm willing to hear arguments to the contrary. =A0=3D= =3D >> >> Russ, I think there is consensus on the requirement currently in the >> document. =A0I don't think the compelling arguments are about what the >> right thing to do is:m y personal opinion is that the requirement is not >> the best technical approach, but that this split is not nearly as bad of >> a thing as I at first thought it was when I started thinking about KARP. >> >> However people have made claims that those doing the implementation work >> in this space strongly prefer the split and that adopting a requirement >> for this split will make it more likely to succeed. =A0I don't think tha= t >> such a split is bad enough on a technical front that we should rule it >> out. So, if the split gets us implementations and the lack of a split >> gets us irrelevance, let's go with the requirement. >> >> So, my question to the WG as a whole is do we actually want to have >> another round of discussion on whether Russ's technical argument above >> is correct? Or are we willing to accept this requirement as a practical >> necessity? My personal opinion is that this requirement is not a >> technical issue and so having this as a technical discussion is not an >> effective strategy. I feel strongly that we should make forward progress >> and do not feel that strongly about whether this requirement should be >> present. >> >> That said, if people want to have the technical discussion I'm happy to >> join it on the list or in private. > > I thought there had already been a good discussion of this point and thou= ght > it had been closed. I'm happy with the requirement as it is written. > > -Michael > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From manav.bhatia@alcatel-lucent.com Wed Jan 12 16:41:03 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 CB1BD3A67EC for ; Wed, 12 Jan 2011 16:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.613 X-Spam-Level: X-Spam-Status: No, score=-5.613 tagged_above=-999 required=5 tests=[AWL=0.986, 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 IUfxf4B13WkA for ; Wed, 12 Jan 2011 16:41:03 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 09B1E3A65A6 for ; Wed, 12 Jan 2011 16:41:02 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p0D0hJv5011033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 12 Jan 2011 18:43:23 -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 p0D0hIvZ027774 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 13 Jan 2011 06:13:19 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 13 Jan 2011 06:13:18 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Thu, 13 Jan 2011 06:13:21 +0530 Thread-Topic: Security Extension for OSPFv2 when using Manual Key Management Thread-Index: AcuyuuDGzY0R41uOSImqcYlBo4YhVw== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@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 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Subject: [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: Thu, 13 Jan 2011 00:41:03 -0000 Hi, Sam, Dacheng and I have written a small draft attempting to fix the issues = that exist when using OSPFv2 with manual keying. It introduces two addition= al variables - the Nonce and the Session ID, that need to be maintained per= neighbor, that will, we believe, fix most issues that currently exist as d= escribed in RFC 6039. As per the KARP design guide we first need to fix the manual keying before = we move to a fully automated key management system for the routing protocol= s. This draft attempts to address the first part, i.e., fixes the issues th= at exist when using manual keying for OSPF. It would be great to hear the feedback from the WG. http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protection-01.txt Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From hartmans@mit.edu Thu Jan 13 08:00: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 D07063A6BB5 for ; Thu, 13 Jan 2011 08:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.859 X-Spam-Level: X-Spam-Status: No, score=-102.859 tagged_above=-999 required=5 tests=[AWL=-0.594, 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 JzrtZUkIOaFT for ; Thu, 13 Jan 2011 08:00:57 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C08683A6BAD for ; Thu, 13 Jan 2011 08:00:57 -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 E204F20239 for ; Thu, 13 Jan 2011 11:01:40 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B3252432C; Thu, 13 Jan 2011 11:03:11 -0500 (EST) From: Sam Hartman To: karp@ietf.org Date: Thu, 13 Jan 2011 11:03:11 -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 Subject: [karp] Negotiation 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, 13 Jan 2011 16:00:58 -0000 At the last meeting, Yinxing Wei asked about our strategy for negotiation of cryptographic parameters. I think this is an important discussion to have. It's another area where I think we may find the security area's default assumptions differ from the routing area. I don't have strong opinions on what the answer is, so perhaps I can try and outline both sides as I understand them. Perhaps this will help get things started. Routing protocols have a fair bit of configuration. For BGP, you need to configure peers, AS information and a heck of a lot of policy. Even for something like OSPF and IS-IS that try to have a fair bit of automated discovery, you need to indicate what area an interface is in. This configuration needs to be consistent and synchronized. As a result, anyone who has more than a couple of routers has mechanisms for managing and updating configuration. Updating what cryptographic algorithms to use in a configuration is not that difficult. One highly undesirable thing in an operational network is when some change has unexpected consequences. Here are a couple of situations that might help understand why an operator is nervous about negotiation. Two peers (A and B) negotiate cryptographic authentication. Before an upgrade, everything is working. B supports SHA-1 and SHA-256, but A only supports SHA-1. A is upgraded and now supports SHA-256. Unfortunately, B's implementation of the routing authentication using SHA-256 is buggy. The upgrade causes things to break. Perhaps you'll argue that's not really an unintended consequence: upgrades sometimes expose bugs in the systems involved in the upgrade. However, negotiation can make problems far more hidden. Consider a network with routers A, B and C. B and C support SHA-256 and SHA-1, but A currently only supports SHA-1. Some protocol with a group key is in-use. A is upgraded; as a result the communication between B and C happens. This can be the case if C's implementation of SHA-256 does not work with B. So, even though neither of the parties directly involved in the communication changed software or configuration, the set of capabilities on the network changed, which changes what is used. On the other hand, negotiation in security protocols is useful. Users don't tend to update configurations. Also, the more you have to configure, the harder it is to get security working. If security parameters can be determined automatically without compromising security, usability is increased. Negotiation will lead to the gradual deployment of better protocols as software is updated. So, negotiation is desirable. Our job is to balance these tradeoffs. From michael_barnes@usa.net Thu Jan 13 08:40: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 9A7903A6BBA for ; Thu, 13 Jan 2011 08:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] 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 oHmcp9q3e9gs for ; Thu, 13 Jan 2011 08:40:24 -0800 (PST) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by core3.amsl.com (Postfix) with ESMTP id A83F03A6BB9 for ; Thu, 13 Jan 2011 08:40:24 -0800 (PST) Received: from cmsout01.mbox.net (cmsout01-lo [127.0.0.1]) by cmsout01.mbox.net (Postfix) with ESMTP id 013672AD0FB; Thu, 13 Jan 2011 16:42:46 +0000 (GMT) X-USANET-Received: from cmsout01.mbox.net [127.0.0.1] by cmsout01.mbox.net via mtad (C8.MAIN.3.71F) with ESMTP id 716PamqQr9920M01; Thu, 13 Jan 2011 16:42:43 -0000 X-USANET-Routed: 3 gwsout-vs Q:bmvirus Received: from cmsapps02.cms.usa.net [165.212.11.138] by cmsout01.mbox.net via smtad (C8.MAIN.3.68M) with ESMTP id XID736PamqQr2415X01; Thu, 13 Jan 2011 16:42:43 -0000 X-USANET-Source: 165.212.11.138 IN michael_barnes@usa.net cmsapps02.cms.usa.net X-USANET-MsgId: XID736PamqQr2415X01 Received: from web01.cms.usa.net [165.212.8.201] by cmsapps02.cms.usa.net (ESMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.71F) with ESMTP id 336PamqQr0768M38; Thu, 13 Jan 2011 16:42:43 -0000 X-USANET-Auth: 165.212.8.201 AUTO michael_barnes@usa.net web01.cms.usa.net Received: from 128.107.114.137 [128.107.114.137] by web01.cms.usa.net (USANET web-mailer C8.MAIN.3.71Y); Thu, 13 Jan 2011 16:42:43 -0000 Date: Thu, 13 Jan 2011 08:42:43 -0800 From: "Michael Barnes" To: Sam Hartman X-Mailer: USANET web-mailer (C8.MAIN.3.71Y) Mime-Version: 1.0 Message-ID: <066Pamqpr7616S01.1294936963@web01.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Z-USANET-MsgId: XID336PamqQr0768X38 Cc: karp@ietf.org Subject: Re: [karp] Negotiation 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, 13 Jan 2011 16:40:25 -0000 Hi Sam, I think there are many ways in which auto negotiation can benefit users a= nd hope we can work through concerns. Configuration complexity is one reason= that operators don't use sophisticated security, so reducing the configuration= effort should increase deployments. I suggest that a negotiation mechanism be available but designed so that = a user can control it, or even disable it, through configuration. This way = if a user has some reason to be concerned that the negotiation mechanism won't= work correctly or some issues might be introduced by using such a mechanism, f= or example if they are using devices from multiple vendors and don't trust t= hose devices to be interoperable, then the operator can carefully control the authentication parameters. Regards, Michael ------ Original Message ------ Received: Thu, 13 Jan 2011 08:03:35 AM PST From: Sam Hartman To: karp@ietf.org Subject: [karp] Negotiation > At the last meeting, Yinxing Wei asked about our strategy for > negotiation of cryptographic parameters. > > I think this is an important discussion to have. It's another area > where I think we may find the security area's default assumptions diffe= r > from the routing area. > > I don't have strong opinions on what the answer is, so perhaps I can tr= y > and outline both sides as I understand them. Perhaps this will help ge= t > things started. > > Routing protocols have a fair bit of configuration. For BGP, you need t= o > configure peers, AS information and a heck of a lot of policy. Even for= > something like OSPF and IS-IS that try to have a fair bit of automated > discovery, you need to indicate what area an interface is in. This > configuration needs to be consistent and synchronized. As a result, > anyone who has more than a couple of routers has mechanisms for managin= g > and updating configuration. Updating what cryptographic algorithms to > use in a configuration is not that difficult. > > One highly undesirable thing in an operational network is when some > change has unexpected consequences. Here are a couple of situations tha= t > might help understand why an operator is nervous about negotiation. Two= > peers (A and B) negotiate cryptographic authentication. Before an > upgrade, everything is working. B supports SHA-1 and SHA-256, but A onl= y > supports SHA-1. A is upgraded and now supports SHA-256. Unfortunately, > B's implementation of the routing authentication using SHA-256 is > buggy. The upgrade causes things to break. Perhaps you'll argue that's= > not really an unintended consequence: upgrades sometimes expose bugs in= > the systems involved in the upgrade. > > However, negotiation can make problems far more hidden. Consider a > network with routers A, B and C. B and C support SHA-256 and SHA-1, but= > A currently only supports SHA-1. Some protocol with a group key is > in-use. A is upgraded; as a result the communication between B and C > happens. This can be the case if C's implementation of SHA-256 does not= > work with B. So, even though neither of the parties directly involved i= n > the communication changed software or configuration, the set of > capabilities on the network changed, which changes what is used. > > On the other hand, negotiation in security protocols is useful. Users > don't tend to update configurations. Also, the more you have to > configure, the harder it is to get security working. If security > parameters can be determined automatically without compromising > security, usability is increased. Negotiation will lead to the gradual > deployment of better protocols as software is updated. So, negotiation > is desirable. > > Our job is to balance these tradeoffs. > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From hartmans@mit.edu Thu Jan 13 08:59: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 5135D3A6B21 for ; Thu, 13 Jan 2011 08:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.838 X-Spam-Level: X-Spam-Status: No, score=-102.838 tagged_above=-999 required=5 tests=[AWL=-0.573, 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 AHWPjbJj1j6m for ; Thu, 13 Jan 2011 08:59:57 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9707A3A6B15 for ; Thu, 13 Jan 2011 08:59:56 -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 05B852016A; Thu, 13 Jan 2011 12:00:42 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1742E432C; Thu, 13 Jan 2011 12:02:12 -0500 (EST) From: Sam Hartman To: "Michael Barnes" References: <066Pamqpr7616S01.1294936963@web01.cms.usa.net> Date: Thu, 13 Jan 2011 12:02:12 -0500 In-Reply-To: <066Pamqpr7616S01.1294936963@web01.cms.usa.net> (Michael Barnes's message of "Thu, 13 Jan 2011 08:42:43 -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: Sam Hartman , karp@ietf.org Subject: Re: [karp] Negotiation 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, 13 Jan 2011 16:59:58 -0000 >>>>> "Michael" == Michael Barnes writes: Michael> I suggest that a negotiation mechanism be available but Michael> designed so that a user can control it, or even disable it, Michael> through configuration. This way if a user has some reason Michael> to be concerned that the negotiation mechanism won't work Michael> correctly or some issues might be introduced by using such Michael> a mechanism, for example if they are using devices from Michael> multiple vendors and don't trust those devices to be Michael> interoperable, then the operator can carefully control the Michael> authentication parameters. I think that the best way to do this if desired to simply permit a user to constrain the set of allowed negotiation results down to one option. That removes the testing complexity of sometimes having negotiation and sometimes not. If we can get consensus behind this I'm fine. I know that Gregory and a couple of others have expressed concerns about this approach. From manav.bhatia@alcatel-lucent.com Thu Jan 13 16:22: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 263DD28C0DD for ; Thu, 13 Jan 2011 16:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.664 X-Spam-Level: X-Spam-Status: No, score=-5.664 tagged_above=-999 required=5 tests=[AWL=0.935, 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 aGsmuRzJJnts for ; Thu, 13 Jan 2011 16:22:00 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id B73F128B23E for ; Thu, 13 Jan 2011 16:21:59 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p0E0OJwe017490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Jan 2011 18:24:22 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0E0ODDM023560 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 14 Jan 2011 05:54:19 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 14 Jan 2011 05:54:13 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Date: Fri, 14 Jan 2011 05:54:07 +0530 Thread-Topic: karp-design-guide reviews Thread-Index: AcuzgVskuUBCuAz/TiOX7OUHnfKqmw== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF083@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 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Subject: [karp] karp-design-guide reviews 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, 14 Jan 2011 00:22:02 -0000 Hi, I confirmed with Sam that we have no outstanding comments from him on the k= arp-design-guide. Asking this on the WG if there are other comments that ha= ve not yet been addressed. If so, please point them out and we will ensure = that they get addressed, if they haven't been already. Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India = From mjbarnes@cisco.com Thu Jan 13 20:57:21 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 A816E3A6C51; Thu, 13 Jan 2011 20:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3xs8j13Fdcu; Thu, 13 Jan 2011 20:57:20 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9ED683A6C53; Thu, 13 Jan 2011 20:57:20 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGpmL02rR7Ht/2dsb2JhbACkVHOlC5hShU8EhGuGK4Mi Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 14 Jan 2011 04:59:44 +0000 Received: from [10.21.92.87] (sjc-vpn5-1111.cisco.com [10.21.92.87]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0E4xir2007740; Fri, 14 Jan 2011 04:59:44 GMT Message-ID: <4D2FD840.3040908@cisco.com> Date: Thu, 13 Jan 2011 20:59:44 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Manav Bhatia References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org, karp@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: Fri, 14 Jan 2011 04:57:22 -0000 Hello Manav, First I want to applaud you and your co-authors for addressing these security problems for OSPF. Thank you. I have some initial questions and comments. During the challenge and response are the hello packets sent immediately to each other or by the standard hello timer? During the challenge and response on a broadcast links, are the packets unicast or multicast? Regarding the new format for hello packets, is this format to be used only during challenge and response, or for all hello packets when this new form of authentication is enabled? RFC2328 defines the AuType field, you've chosen to rename it to AuthType. I suggest we continue to use AuType for continuity. In the figures which illustrate the header and hello packet fields, I suggest that instead of showing two words as just "Authentication" that the figure shows the sub-fields. In the context of this specification those words will have a single definition, so there is no reason to leave them loosely defined. Please describe how LLS will be covered using this new authentication type. Regards, Michael On 01/12/2011 04:43 PM, Bhatia, Manav (Manav) wrote: > Hi, > > Sam, Dacheng and I have written a small draft attempting to fix the issues that exist when using OSPFv2 with manual keying. It introduces two additional variables - the Nonce and the Session ID, that need to be maintained per neighbor, that will, we believe, fix most issues that currently exist as described in RFC 6039. > > As per the KARP design guide we first need to fix the manual keying before we move to a fully automated key management system for the routing protocols. This draft attempts to address the first part, i.e., fixes the issues that exist when using manual keying for OSPF. > > It would be great to hear the feedback from the WG. > > http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protection-01.txt > > 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 Fri Jan 14 00:53:09 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 916433A6BAD; Fri, 14 Jan 2011 00:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.753 X-Spam-Level: X-Spam-Status: No, score=-5.753 tagged_above=-999 required=5 tests=[AWL=0.846, 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 f4V03raGTeUl; Fri, 14 Jan 2011 00:53:08 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 7F1463A6B6F; Fri, 14 Jan 2011 00:53:08 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p0E8tRpZ020258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Jan 2011 02:55:31 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0E8tRf1027265 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Jan 2011 14:25:27 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 14 Jan 2011 14:25:26 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes Date: Fri, 14 Jan 2011 14:25:24 +0530 Thread-Topic: [karp] Security Extension for OSPFv2 when using Manual Key Management Thread-Index: Acuzp+D60rw+y5ChR+63omo6zv31LAAH3Wrw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> In-Reply-To: <4D2FD840.3040908@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@ietf.org" , "karp@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: Fri, 14 Jan 2011 08:53:09 -0000 Hi Michael, =20 > First I want to applaud you and your co-authors for addressing these=20 > security problems for OSPF. Thank you. Thanks Mike! >=20 > I have some initial questions and comments. >=20 > During the challenge and response are the hello packets sent=20 > immediately=20 > to each other or by the standard hello timer? I think it should be done immediately without waiting for the Hello timer t= o expire. >=20 > During the challenge and response on a broadcast links, are=20 > the packets=20 > unicast or multicast? Multicast. >=20 > Regarding the new format for hello packets, is this format to be used=20 > only during challenge and response, or for all hello packets=20 > when this=20 > new form of authentication is enabled? This has to be used *all* the time. >=20 > RFC2328 defines the AuType field, you've chosen to rename it to=20 > AuthType. I suggest we continue to use AuType for continuity. Sure, will do that. >=20 > In the figures which illustrate the header and hello packet fields, I=20 > suggest that instead of showing two words as just=20 > "Authentication" that=20 > the figure shows the sub-fields. In the context of this specification=20 > those words will have a single definition, so there is no reason to=20 > leave them loosely defined. It's a typo. We need to remove the two fields shown as Authentication from = the two figures! >=20 > Please describe how LLS will be covered using this new=20 > authentication type. This extension has no bearing on the LLS since LLS isnt really a part of th= e OSPF payload. Its length is not included in the length of the OSPF packet= , but is included in the IPv4 packet length. Is there something specific that you are looking at? And thanks for your comments! Cheers, Manav >=20 > Regards, > Michael >=20 >=20 > On 01/12/2011 04:43 PM, Bhatia, Manav (Manav) wrote: > > Hi, > > > > Sam, Dacheng and I have written a small draft attempting to=20 > fix the issues that exist when using OSPFv2 with manual=20 > keying. It introduces two additional variables - the Nonce=20 > and the Session ID, that need to be maintained per neighbor,=20 > that will, we believe, fix most issues that currently exist=20 > as described in RFC 6039. > > > > As per the KARP design guide we first need to fix the=20 > manual keying before we move to a fully automated key=20 > management system for the routing protocols. This draft=20 > attempts to address the first part, i.e., fixes the issues=20 > that exist when using manual keying for OSPF. > > > > It would be great to hear the feedback from the WG. > > > >=20 > http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protect > ion-01.txt > > > > Cheers, Manav > > > > -- > > Manav Bhatia, > > IP Division, Alcatel-Lucent, > > Bangalore - India > > > > > > _______________________________________________ > > karp mailing list > > karp@ietf.org > > https://www.ietf.org/mailman/listinfo/karp > > > = From mjbarnes@cisco.com Fri Jan 14 02:39: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 119E63A6AFB; Fri, 14 Jan 2011 02:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t39S79v4894O; Fri, 14 Jan 2011 02:39:54 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 57BA03A6A40; Fri, 14 Jan 2011 02:39:53 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIO3L02rR7H+/2dsb2JhbACkVnOkSphGhU8EhGuGK4Mi Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 14 Jan 2011 10:42:18 +0000 Received: from [10.21.91.228] (sjc-vpn5-996.cisco.com [10.21.91.228]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0EAgIMW009665; Fri, 14 Jan 2011 10:42:18 GMT Message-ID: <4D30288A.8080505@cisco.com> Date: Fri, 14 Jan 2011 02:42:18 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Manav Bhatia References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" , "karp@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: Fri, 14 Jan 2011 10:39:55 -0000 Hi Manav, On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: > Hi Michael, > >> First I want to applaud you and your co-authors for addressing these >> security problems for OSPF. Thank you. > > Thanks Mike! > >> >> I have some initial questions and comments. >> >> During the challenge and response are the hello packets sent >> immediately >> to each other or by the standard hello timer? > > I think it should be done immediately without waiting for the Hello timer to expire. > >> >> During the challenge and response on a broadcast links, are >> the packets >> unicast or multicast? > > Multicast. > >> >> Regarding the new format for hello packets, is this format to be used >> only during challenge and response, or for all hello packets >> when this >> new form of authentication is enabled? > > This has to be used *all* the time. Please clarify the above three points in the document. >> >> RFC2328 defines the AuType field, you've chosen to rename it to >> AuthType. I suggest we continue to use AuType for continuity. > > Sure, will do that. > >> >> In the figures which illustrate the header and hello packet fields, I >> suggest that instead of showing two words as just >> "Authentication" that >> the figure shows the sub-fields. In the context of this specification >> those words will have a single definition, so there is no reason to >> leave them loosely defined. > > It's a typo. We need to remove the two fields shown as Authentication from the two figures! > >> >> Please describe how LLS will be covered using this new >> authentication type. > > This extension has no bearing on the LLS since LLS isnt really a part of the OSPF payload. Its length is not included in the length of the OSPF packet, but is included in the IPv4 packet length. > > Is there something specific that you are looking at? LLS part of OSPF also needs to be authenticated so this draft really needs to cover it as well. Thanks, Michael From mjbarnes@cisco.com Fri Jan 14 02:45: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 A09483A6B61; Fri, 14 Jan 2011 02:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOgJsW+25zGL; Fri, 14 Jan 2011 02:45:57 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E39133A6B4F; Fri, 14 Jan 2011 02:45:57 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADe4L02rR7Hu/2dsb2JhbACkVnOkUphGhU8EhGuGK4Mi Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 14 Jan 2011 10:48:23 +0000 Received: from [10.21.91.228] (sjc-vpn5-996.cisco.com [10.21.91.228]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0EAmMfp003552; Fri, 14 Jan 2011 10:48:22 GMT Message-ID: <4D3029F7.6040107@cisco.com> Date: Fri, 14 Jan 2011 02:48:23 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Manav Bhatia References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" , "karp@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: Fri, 14 Jan 2011 10:45:58 -0000 Hi Manav, I wanted to address this point separately. On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: >> > Regarding the new format for hello packets, is this format to be used >> > only during challenge and response, or for all hello packets >> > when this >> > new form of authentication is enabled? > This has to be used*all* the time. I'm not very excited about a 3x increase in the number of bytes per neighbor. (For those who haven't read the draft, it changes the Hello packet so that it contains 12 bytes for each neighbor over the current 4 bytes per neighbor.) I have to wonder if this is really necessary for each and every hello packet. I'm certainly not a security expert, but it seems to me that once we have verified the neighbor's session ID we shouldn't continue to need to receive our own session ID and nonce back in every hello packet. Did you consider if this can't be optimized? Thanks, Michael From mjbarnes@cisco.com Fri Jan 14 03:00: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 05E0F3A6B6A; Fri, 14 Jan 2011 03:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZsTJu2TcGrn; Fri, 14 Jan 2011 03:00:47 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 310563A6BA9; Fri, 14 Jan 2011 03:00:47 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG+8L02rRN+J/2dsb2JhbACkVnOkOJhChU8EhGuGK4Mi Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 14 Jan 2011 11:03:12 +0000 Received: from [10.21.91.228] (sjc-vpn5-996.cisco.com [10.21.91.228]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0EB3CBO013778; Fri, 14 Jan 2011 11:03:12 GMT Message-ID: <4D302D70.2010409@cisco.com> Date: Fri, 14 Jan 2011 03:03:12 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Manav Bhatia References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" , "karp@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: Fri, 14 Jan 2011 11:00:48 -0000 Hi Manav, On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: >> In the figures which illustrate the header and hello packet fields, I >> > suggest that instead of showing two words as just >> > "Authentication" that >> > the figure shows the sub-fields. In the context of this specification >> > those words will have a single definition, so there is no reason to >> > leave them loosely defined. > It's a typo. We need to remove the two fields shown as Authentication from the two figures! If you remove those, then where are sequence number, Key ID & Auth Data Length fields in the Hello packets? Thanks, Michael From manav.bhatia@alcatel-lucent.com Fri Jan 14 03:35:40 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 E9EB73A6C5D; Fri, 14 Jan 2011 03:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.792 X-Spam-Level: X-Spam-Status: No, score=-5.792 tagged_above=-999 required=5 tests=[AWL=0.807, 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 XF63yOg8hWk0; Fri, 14 Jan 2011 03:35:40 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 16CDD3A6B61; Fri, 14 Jan 2011 03:35:39 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p0EBbxjF020059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Jan 2011 05:38:02 -0600 (CST) 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 p0EBbxKe006432 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Jan 2011 17:07:59 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 14 Jan 2011 17:07:59 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes Date: Fri, 14 Jan 2011 17:07:58 +0530 Thread-Topic: [karp] Security Extension for OSPFv2 when using Manual Key Management Thread-Index: Acuz2rFetIf66XshSGKIhAsVNuoLegAAys2g Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF114@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D302D70.2010409@cisco.com> In-Reply-To: <4D302D70.2010409@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@ietf.org" , "karp@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: Fri, 14 Jan 2011 11:35:41 -0000 Hi Michael, Thanks for catching this - will fix it in the next revision. I think the OSPF header should remain as is. Each router should prepend its= Nonce and Session ID information before the Auth payload.=20 Cheers, Manav > -----Original Message----- > From: Michael Barnes [mailto:mjbarnes@cisco.com]=20 > Sent: Friday, January 14, 2011 4.33 PM > To: Bhatia, Manav (Manav) > Cc: ospf@ietf.org; karp@ietf.org > Subject: Re: [karp] Security Extension for OSPFv2 when using=20 > Manual Key Management >=20 > Hi Manav, >=20 > On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: > >> In the figures which illustrate the header and hello=20 > packet fields, I > >> > suggest that instead of showing two words as just > >> > "Authentication" that > >> > the figure shows the sub-fields. In the context of this=20 > specification > >> > those words will have a single definition, so there is=20 > no reason to > >> > leave them loosely defined. >=20 > > It's a typo. We need to remove the two fields shown as=20 > Authentication from the two figures! >=20 > If you remove those, then where are sequence number, Key ID &=20 > Auth Data=20 > Length fields in the Hello packets? >=20 > Thanks, > Michael > = From manav.bhatia@alcatel-lucent.com Fri Jan 14 03:35:41 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 9F8293A6B61; Fri, 14 Jan 2011 03:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.772, 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 oHFNXCqcekem; Fri, 14 Jan 2011 03:35:40 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A83AC3A6BD7; Fri, 14 Jan 2011 03:35:40 -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 p0EBc1b8020076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Jan 2011 05:38:04 -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 p0EBc00u005868 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Jan 2011 17:08:00 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 14 Jan 2011 17:08:00 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes Date: Fri, 14 Jan 2011 17:07:56 +0530 Thread-Topic: [karp] Security Extension for OSPFv2 when using Manual Key Management Thread-Index: Acuz18cTNuQVZLxqQDuDJ8+WAZUOygAB4hxw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF116@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D30288A.8080505@cisco.com> In-Reply-To: <4D30288A.8080505@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "ospf@ietf.org" , "karp@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: Fri, 14 Jan 2011 11:35:41 -0000 Hi Michael, > > This extension has no bearing on the LLS since LLS isnt=20 > really a part of the OSPF payload. Its length is not included=20 > in the length of the OSPF packet, but is included in the IPv4=20 > packet length. > > > > Is there something specific that you are looking at? >=20 > LLS part of OSPF also needs to be authenticated so this draft really=20 > needs to cover it as well. The LLS processing remains exactly the same. Will cover this too in the nex= t cut. Thanks, Manav= From manav.bhatia@alcatel-lucent.com Fri Jan 14 03:36:06 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 C92B93A6B61; Fri, 14 Jan 2011 03:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=0.740, 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 GpvxeDCTvy7D; Fri, 14 Jan 2011 03:36:06 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id D81E33A6C5C; Fri, 14 Jan 2011 03:36:05 -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 p0EBc1lZ020075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Jan 2011 05:38:04 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0EBc0UB005867 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Jan 2011 17:08:00 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 14 Jan 2011 17:07:59 +0530 From: "Bhatia, Manav (Manav)" To: Michael Barnes Date: Fri, 14 Jan 2011 17:05:50 +0530 Thread-Topic: [karp] Security Extension for OSPFv2 when using Manual Key Management Thread-Index: Acuz2JUAjh1hocm7TYGtMDxyabrhUAABb82w Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DF115@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3029F7.6040107@cisco.com> In-Reply-To: <4D3029F7.6040107@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "ospf@ietf.org" , "karp@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: Fri, 14 Jan 2011 11:36:06 -0000 Hi Michael, > On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: > >> > Regarding the new format for hello packets, is this=20 > format to be used > >> > only during challenge and response, or for all hello packets > >> > when this > >> > new form of authentication is enabled? >=20 > > This has to be used*all* the time. >=20 > I'm not very excited about a 3x increase in the number of bytes per=20 > neighbor. (For those who haven't read the draft, it changes the Hello=20 > packet so that it contains 12 bytes for each neighbor over=20 > the current 4=20 > bytes per neighbor.) I have to wonder if this is really necessary for=20 > each and every hello packet. I'm certainly not a security=20 > expert, but it=20 > seems to me that once we have verified the neighbor's session ID we=20 > shouldn't continue to need to receive our own session ID and=20 > nonce back=20 > in every hello packet. Did you consider if this can't be optimized? Nonce and Session IDs are essential to protect against inter and intra-repl= ay attacks. While I think we need to carry them all the time, I am not prec= luding the possibility of some optimization that can get in here. The idea = behind submitting this draft was to initiate a discussion on how to start s= ecuring OSPF when its using manual keying. I am also ok if we start this di= scussion and arrive on a solution that's quite divergent from the one that'= s presented here! Cheers, Manav= From hartmans@mit.edu Fri Jan 14 04:32: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 E120D3A6AAC; Fri, 14 Jan 2011 04:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 0AhHyxDiqTJd; Fri, 14 Jan 2011 04:32:16 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id F117A3A6AA4; Fri, 14 Jan 2011 04:32:15 -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 7FB1B200D5; Fri, 14 Jan 2011 07:33:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A401B432C; Fri, 14 Jan 2011 07:34:31 -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> Date: Fri, 14 Jan 2011 07:34:31 -0500 In-Reply-To: <4D3029F7.6040107@cisco.com> (Michael Barnes's message of "Fri, 14 Jan 2011 02:48:23 -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 X-Mailman-Approved-At: Fri, 14 Jan 2011 08:06:49 -0800 Cc: "ospf@ietf.org" , "karp@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: Fri, 14 Jan 2011 12:32:17 -0000 >>>>> "Michael" == Michael Barnes writes: Michael> Hi Manav, I wanted to address this point separately. Michael> On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: >>> > Regarding the new format for hello packets, is this format to >>> be used > only during challenge and response, or for all hello >>> packets > when this > new form of authentication is enabled? >> This has to be used*all* the time. Michael> I'm not very excited about a 3x increase in the number of Michael> bytes per neighbor. (For those who haven't read the draft, Michael> it changes the Hello packet so that it contains 12 bytes Michael> for each neighbor over the current 4 bytes per neighbor.) I Michael> have to wonder if this is really necessary for each and Michael> every hello packet. I'm certainly not a security expert, Michael> but it seems to me that once we have verified the Michael> neighbor's session ID we shouldn't continue to need to Michael> receive our own session ID and nonce back in every hello Michael> packet. Did you consider if this can't be optimized? We can certainly look at optimizing. However, note that currently we don't really have a well defined state of challenging. You need to look at a neighbor's idea of your session ID and nonce whenever the state is not at least two-way. So, one of the tricky questions is how does a neighbor know when to include this information? We could have separate authentication challenge packets. However, the advantage of the current approach is that I think we can get to a point where we have one or two extra packets total for a cold-start situation, rather than an extra packet or two per neighbor. I don't know that the current rules for receiving and sending packets actually achieve this, but I believe we can get there with some minor changes. However, we can definitely think about optimizations. I believe the current text does actually say that hellos are sent immediately if we need to challenge someone, at least if we have not sent a challenge hello too recently. Take a look at the detailed description of the section on nonce triggers. --Sam From glen.kent@gmail.com Sat Jan 15 14:20:42 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 7FCBB3A6B9B; Sat, 15 Jan 2011 14:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.971 X-Spam-Level: X-Spam-Status: No, score=-2.971 tagged_above=-999 required=5 tests=[AWL=0.628, 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 6aJvAmlSNu27; Sat, 15 Jan 2011 14:20:39 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 465B93A6B46; Sat, 15 Jan 2011 14:20:38 -0800 (PST) Received: by ewy8 with SMTP id 8so2134047ewy.31 for ; Sat, 15 Jan 2011 14:23:07 -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=q4pP4J2uLCZ5jsV9+wNSB5ggW/emEIYvHiYWC0eAd/I=; b=r3vErmzb90+aho5JqHo5NKjN/PeQkflAsHz/YLD100vc2zmcnr09Y8NcQqb4U+pDYX q9P/Cga3918kNJHRBvQE1IYus4Ltf/oXHliCpGgNy6evv1Inqw7duGshgXp1koVzCzw3 1EjZ7oL0yQGTh6QfxJT/BJUEMYwSDdnWnkmbQ= 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=hcYGilrx1+GSy1i+xd8ggLbJ3Ed2r2znKfhpOML/hDpKzdq/xLYac0i3Foq6jdEvq/ nG3IrrP/8ltr0djFUKhRQ3eDrscdrRlyV9k4W0V6NogLuJhBdPb1DN3uchi77EogYlrk hcvpdGbPGEemXD4O5DQqULnRN7P/ULjKzeHiU= MIME-Version: 1.0 Received: by 10.14.53.75 with SMTP id f51mr1887369eec.4.1295130185855; Sat, 15 Jan 2011 14:23:05 -0800 (PST) Received: by 10.14.125.146 with HTTP; Sat, 15 Jan 2011 14:23:05 -0800 (PST) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3029F7.6040107@cisco.com> Date: Sun, 16 Jan 2011 03:53:05 +0530 Message-ID: From: Glen Kent To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ospf@ietf.org" , "karp@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: Sat, 15 Jan 2011 22:20:42 -0000 I'll confess that it took me some time to really understand the challenge protocol that you have introduced and the utility of the nonce and the session IDs that you are carrying. I attribute that to the language used in the draft which i think can be considerably improved. I, as someone else also noted in the list, could not find the Key ID and the cryptographic sequence number associated with each packet in the current draft. This was perhaps overwritten by the nonce and the session details that you have defined. You will have to move this information out somewhere else and bring back these two parameters so that this scheme works. Assuming that this can be done, i must say that this is i believe the first serious attempt at really solving the inter session replay attacks in any protocol that uses manual keying. Kudos to the authors for that. I hope to see this being presented in Prague= . Glen On Fri, Jan 14, 2011 at 6:04 PM, Sam Hartman wrote: >>>>>> "Michael" =3D=3D Michael Barnes writes: > > =A0 =A0Michael> Hi Manav, I wanted to address this point separately. > > =A0 =A0Michael> On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: > =A0 =A0>>> > Regarding the new format for hello packets, is this format t= o > =A0 =A0>>> be used > only during challenge and response, or for all hello > =A0 =A0>>> packets > when this > new form of authentication is enabled? > > =A0 =A0>> This has to be used*all* the time. > > =A0 =A0Michael> I'm not very excited about a 3x increase in the number of > =A0 =A0Michael> bytes per neighbor. (For those who haven't read the draft= , > =A0 =A0Michael> it changes the Hello packet so that it contains 12 bytes > =A0 =A0Michael> for each neighbor over the current 4 bytes per neighbor.)= I > =A0 =A0Michael> have to wonder if this is really necessary for each and > =A0 =A0Michael> every hello packet. I'm certainly not a security expert, > =A0 =A0Michael> but it seems to me that once we have verified the > =A0 =A0Michael> neighbor's session ID we shouldn't continue to need to > =A0 =A0Michael> receive our own session ID and nonce back in every hello > =A0 =A0Michael> packet. Did you consider if this can't be optimized? > > We can certainly look at optimizing. =A0However, note that currently we > don't really have a well defined state of challenging. =A0You need to loo= k > at a neighbor's idea of your session ID and nonce whenever the state is > not at least two-way. > So, one of the tricky questions is how does a neighbor =A0know when to > include this information? > > We could have separate authentication challenge packets. =A0However, the > advantage of the current approach is that I think we can get to a point > where we have one or two extra packets total for a cold-start situation, > rather than an extra packet or two per neighbor. =A0I don't know that the > current rules for receiving and sending packets actually achieve this, > but I believe we can get there with some minor changes. > > However, we can definitely think about optimizations. > > I believe the current text does actually say that hellos are sent > immediately if we need to challenge someone, at least if we have not > sent a challenge hello too recently. =A0Take a look at the detailed > description of the section on nonce triggers. > > --Sam > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From liang.xiaoping@zte.com.cn Tue Jan 18 23:29: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 14EA63A70D6; Tue, 18 Jan 2011 23:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.545 X-Spam-Level: X-Spam-Status: No, score=-95.545 tagged_above=-999 required=5 tests=[AWL=1.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 hDjGUKP2lpPu; Tue, 18 Jan 2011 23:29:12 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 336DD3A6E7E; Tue, 18 Jan 2011 23:29:08 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205952175658078; Wed, 19 Jan 2011 15:27:01 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 66283.8687907248; Wed, 19 Jan 2011 15:24:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p0J7VUZ4024009; Wed, 19 Jan 2011 15:31:30 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: To: Glen Kent MIME-Version: 1.0 X-KeepSent: D1C1E647:0579D6E7-4825781D:0027CF84; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Wed, 19 Jan 2011 15:31:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-19 15:31:32, Serialize complete at 2011-01-19 15:31:32 Content-Type: multipart/alternative; boundary="=_alternative 0029552E4825781D_=" X-MAIL: mse02.zte.com.cn p0J7VUZ4024009 Cc: karp-bounces@ietf.org, karp@ietf.org, Sam Hartman Subject: Re: [karp] Responses to Comments for 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, 19 Jan 2011 07:29:14 -0000 This is a multipart message in MIME format. --=_alternative 0029552E4825781D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUnVzcywgU2FtLCBNaWNoYWVsIGFuZCBHbGVuLA0KDQpJIGFncmVlIHRvIHRoZSBjdXJyZW50 IHRocmVhdHMtcmVxcyBkb2N1bWVudCwgdG9vLiBJZiBhbnkgbmV3IHNpdHVhdGlvbiANCmhhcHBl biwgb3IgdGhlcmUgaXMgcG9pbnQgdGhhdCBjYW5ub3QgYmUgYWNoaWV2ZWQgY29uc2Vuc3VzIGJ5 IGFsbCBhdCB0aGUgDQp0aW1lIGJlaW5nLCB0aGUgZG9jdW1lbnQgY2FuIGJlIHVwZGF0ZWQgYW55 d2F5IF5fXiANCg0KQ2hlZXJzLA0KRWxsZW4gKFhpYW9waW5nIExpYW5nKQ0KICANCg0KDQoNCkds ZW4gS2VudCA8Z2xlbi5rZW50QGdtYWlsLmNvbT4gDQq3orz+yMs6ICBrYXJwLWJvdW5jZXNAaWV0 Zi5vcmcNCjIwMTEtMDEtMTIgMDg6NTYNCg0KytW8/sjLDQpNaWNoYWVsIEJhcm5lcyA8bWljaGFl bF9iYXJuZXNAdXNhLm5ldD4NCrOty80NCmthcnBAaWV0Zi5vcmcsIFNhbSBIYXJ0bWFuIDxoYXJ0 bWFucy1pZXRmQG1pdC5lZHU+DQrW98ziDQpSZTogW2thcnBdIFJlc3BvbnNlcyB0byBDb21tZW50 cyBmb3IgZHJhZnQtaWV0Zi1rYXJwLXRocmVhdHMtcmVxcy0wMQ0KDQoNCg0KDQoNCg0KSSBhZ3Jl ZSBhbmQgaSB3b3VsZCBsaWtlIGl0IHRvIHJlbWFpbiB0aGUgd2F5IGl0IGlzIGluIHRoZQ0KdGhy ZWF0cy1yZXFzIGRvY3VtZW50LiBXZSBjYW4gY29tZSBiYWNrIHRvIGl0IGxhdGVyIGlmIHdlIGZp bmQgdGhhdA0KdGhpcyBkZWNvdXBsaW5nIGlzIG5vdCBwb3NzaWJsZSBvciBpcyBoaWdobHkgdW5v cHRpbWFsLg0KDQpHbGVuDQoNCk9uIFR1ZSwgSmFuIDExLCAyMDExIGF0IDQ6MjQgQU0sIE1pY2hh ZWwgQmFybmVzIDxtaWNoYWVsX2Jhcm5lc0B1c2EubmV0PiANCndyb3RlOg0KPiBIaSBTYW4gJiBS dXNzLA0KPg0KPiBGcm9tOiBTYW0gSGFydG1hbiA8aGFydG1hbnMtaWV0ZkBtaXQuZWR1Pg0KPiBU bzogUnVzcyBXaGl0ZSA8cnVzc0BjaXNjby5jb20+Q2M6IGthcnBAaWV0Zi5vcmcNCj4NCj4+ID4+ Pj4+ICJSdXNzIiA9PSBSdXNzIFdoaXRlIDxydXNzQGNpc2NvLmNvbT4gd3JpdGVzOg0KPj4NCj4+ DQo+PiAgICAgUnVzcz4gU28gbXkgc2Vuc2UgaXMgdGhhdCBkaXZpZGluZyB0aGUgcmVhY2hhYmls aXR5IGNvbnRyb2wgcGxhbmUNCj4+ICAgICBSdXNzPiBmcm9tIHRoZSBlbmNyeXB0aW9uIGNvbnRy b2wgcGxhbmUgaXMgYSAiZ29vZCB0aGluZywiIGxpa2VseSANCnRvDQo+PiAgICAgUnVzcz4gcmVz dWx0IGluIGZld2VyIHBvb3JseSB1bmRlcnN0b29kIGZlZWRiYWNrIGxvb3BzLCBhbmQgZmV3ZXIN Cj4+ICAgICBSdXNzPiB1bmludGVuZGVkIGNvbnNlcXVlbmNlcy4gSSdtIHByZXR0eSBzdHJvbmds eSBpbiBmYXZvciBvZg0KPj4gICAgIFJ1c3M+IHNwbGl0dGluZyB0aGVzZSB3aGVyZSBwb3NzaWJs ZSwgYW5kIG1ha2luZyB0aGUgQVBJIGJldHdlZW4gYXMNCj4+ICAgICBSdXNzPiB0cmFuc3BhcmVu dCBhcyBwb3NzaWJsZS4NCj4+DQo+PiAgICAgUnVzcz4gQnV0IEknbSB3aWxsaW5nIHRvIGhlYXIg YXJndW1lbnRzIHRvIHRoZSBjb250cmFyeS4gID09DQo+Pg0KPj4gUnVzcywgSSB0aGluayB0aGVy ZSBpcyBjb25zZW5zdXMgb24gdGhlIHJlcXVpcmVtZW50IGN1cnJlbnRseSBpbiB0aGUNCj4+IGRv Y3VtZW50LiAgSSBkb24ndCB0aGluayB0aGUgY29tcGVsbGluZyBhcmd1bWVudHMgYXJlIGFib3V0 IHdoYXQgdGhlDQo+PiByaWdodCB0aGluZyB0byBkbyBpczptIHkgcGVyc29uYWwgb3BpbmlvbiBp cyB0aGF0IHRoZSByZXF1aXJlbWVudCBpcyANCm5vdA0KPj4gdGhlIGJlc3QgdGVjaG5pY2FsIGFw cHJvYWNoLCBidXQgdGhhdCB0aGlzIHNwbGl0IGlzIG5vdCBuZWFybHkgYXMgYmFkIA0Kb2YNCj4+ IGEgdGhpbmcgYXMgSSBhdCBmaXJzdCB0aG91Z2h0IGl0IHdhcyB3aGVuIEkgc3RhcnRlZCB0aGlu a2luZyBhYm91dCANCktBUlAuDQo+Pg0KPj4gSG93ZXZlciBwZW9wbGUgaGF2ZSBtYWRlIGNsYWlt cyB0aGF0IHRob3NlIGRvaW5nIHRoZSBpbXBsZW1lbnRhdGlvbiANCndvcmsNCj4+IGluIHRoaXMg c3BhY2Ugc3Ryb25nbHkgcHJlZmVyIHRoZSBzcGxpdCBhbmQgdGhhdCBhZG9wdGluZyBhIHJlcXVp cmVtZW50DQo+PiBmb3IgdGhpcyBzcGxpdCB3aWxsIG1ha2UgaXQgbW9yZSBsaWtlbHkgdG8gc3Vj Y2VlZC4gIEkgZG9uJ3QgdGhpbmsgdGhhdA0KPj4gc3VjaCBhIHNwbGl0IGlzIGJhZCBlbm91Z2gg b24gYSB0ZWNobmljYWwgZnJvbnQgdGhhdCB3ZSBzaG91bGQgcnVsZSBpdA0KPj4gb3V0LiBTbywg aWYgdGhlIHNwbGl0IGdldHMgdXMgaW1wbGVtZW50YXRpb25zIGFuZCB0aGUgbGFjayBvZiBhIHNw bGl0DQo+PiBnZXRzIHVzIGlycmVsZXZhbmNlLCBsZXQncyBnbyB3aXRoIHRoZSByZXF1aXJlbWVu dC4NCj4+DQo+PiBTbywgbXkgcXVlc3Rpb24gdG8gdGhlIFdHIGFzIGEgd2hvbGUgaXMgZG8gd2Ug YWN0dWFsbHkgd2FudCB0byBoYXZlDQo+PiBhbm90aGVyIHJvdW5kIG9mIGRpc2N1c3Npb24gb24g d2hldGhlciBSdXNzJ3MgdGVjaG5pY2FsIGFyZ3VtZW50IGFib3ZlDQo+PiBpcyBjb3JyZWN0PyBP ciBhcmUgd2Ugd2lsbGluZyB0byBhY2NlcHQgdGhpcyByZXF1aXJlbWVudCBhcyBhIHByYWN0aWNh bA0KPj4gbmVjZXNzaXR5PyBNeSBwZXJzb25hbCBvcGluaW9uIGlzIHRoYXQgdGhpcyByZXF1aXJl bWVudCBpcyBub3QgYQ0KPj4gdGVjaG5pY2FsIGlzc3VlIGFuZCBzbyBoYXZpbmcgdGhpcyBhcyBh IHRlY2huaWNhbCBkaXNjdXNzaW9uIGlzIG5vdCBhbg0KPj4gZWZmZWN0aXZlIHN0cmF0ZWd5LiBJ IGZlZWwgc3Ryb25nbHkgdGhhdCB3ZSBzaG91bGQgbWFrZSBmb3J3YXJkIA0KcHJvZ3Jlc3MNCj4+ IGFuZCBkbyBub3QgZmVlbCB0aGF0IHN0cm9uZ2x5IGFib3V0IHdoZXRoZXIgdGhpcyByZXF1aXJl bWVudCBzaG91bGQgYmUNCj4+IHByZXNlbnQuDQo+Pg0KPj4gVGhhdCBzYWlkLCBpZiBwZW9wbGUg d2FudCB0byBoYXZlIHRoZSB0ZWNobmljYWwgZGlzY3Vzc2lvbiBJJ20gaGFwcHkgdG8NCj4+IGpv aW4gaXQgb24gdGhlIGxpc3Qgb3IgaW4gcHJpdmF0ZS4NCj4NCj4gSSB0aG91Z2h0IHRoZXJlIGhh ZCBhbHJlYWR5IGJlZW4gYSBnb29kIGRpc2N1c3Npb24gb2YgdGhpcyBwb2ludCBhbmQgDQp0aG91 Z2h0DQo+IGl0IGhhZCBiZWVuIGNsb3NlZC4gSSdtIGhhcHB5IHdpdGggdGhlIHJlcXVpcmVtZW50 IGFzIGl0IGlzIHdyaXR0ZW4uDQo+DQo+IC1NaWNoYWVsDQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGthcnAgbWFpbGluZyBsaXN0DQo+IGth cnBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9rYXJw DQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Ka2Fy cCBtYWlsaW5nIGxpc3QNCmthcnBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8va2FycA0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJv cGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRp b24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQg dG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhl IGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFu ZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo b20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2 aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVh bCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQg U3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0029552E4825781D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBSdXNzLCBTYW0sIE1pY2hhZWwgYW5kIEdsZW4sPC9m b250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIGFncmVlIHRvIHRoZSBjdXJy ZW50IHRocmVhdHMtcmVxcyBkb2N1bWVudCwgdG9vLg0KSWYgYW55IG5ldyBzaXR1YXRpb24gaGFw cGVuLCBvciB0aGVyZSBpcyBwb2ludCB0aGF0IGNhbm5vdCBiZSBhY2hpZXZlZA0KY29uc2Vuc3Vz IGJ5IGFsbCBhdCB0aGUgdGltZSBiZWluZywgdGhlIGRvY3VtZW50IGNhbiBiZSB1cGRhdGVkIGFu eXdheQ0KXl9eIDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Q2hlZXJz LDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+RWxsZW4gKFhpYW9waW5nIExpYW5n KTwvZm9udD48L3R0Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZu YnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPg0KPC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0z NSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkdsZW4gS2VudCAmbHQ7Z2xlbi5r ZW50QGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPreivP7IyzogJm5ic3A7a2FycC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDEtMTIgMDg6NTY8L2ZvbnQ+DQo8 dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7Iyzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+TWljaGFlbCBC YXJuZXMgJmx0O21pY2hhZWxfYmFybmVzQHVzYS5uZXQmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5r YXJwQGlldGYub3JnLCBTYW0gSGFydG1hbiAmbHQ7aGFydG1hbnMtaWV0ZkBtaXQuZWR1Jmd0Ozwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtrYXJwXSBSZXNwb25zZXMgdG8gQ29tbWVudHMgZm9yDQpk cmFmdC1pZXRmLWthcnAtdGhyZWF0cy1yZXFzLTAxPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFi bGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIGFncmVlIGFuZCBpIHdvdWxkIGxpa2Ug aXQgdG8gcmVtYWluIHRoZSB3YXkgaXQgaXMNCmluIHRoZTxicj4NCnRocmVhdHMtcmVxcyBkb2N1 bWVudC4gV2UgY2FuIGNvbWUgYmFjayB0byBpdCBsYXRlciBpZiB3ZSBmaW5kIHRoYXQ8YnI+DQp0 aGlzIGRlY291cGxpbmcgaXMgbm90IHBvc3NpYmxlIG9yIGlzIGhpZ2hseSB1bm9wdGltYWwuPGJy Pg0KPGJyPg0KR2xlbjxicj4NCjxicj4NCk9uIFR1ZSwgSmFuIDExLCAyMDExIGF0IDQ6MjQgQU0s IE1pY2hhZWwgQmFybmVzICZsdDttaWNoYWVsX2Jhcm5lc0B1c2EubmV0Jmd0Ow0Kd3JvdGU6PGJy Pg0KJmd0OyBIaSBTYW4gJmFtcDsgUnVzcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBGcm9tOiBTYW0g SGFydG1hbiAmbHQ7aGFydG1hbnMtaWV0ZkBtaXQuZWR1Jmd0Ozxicj4NCiZndDsgVG86IFJ1c3Mg V2hpdGUgJmx0O3J1c3NAY2lzY28uY29tJmd0O0NjOiBrYXJwQGlldGYub3JnPGJyPg0KJmd0Ozxi cj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZxdW90O1J1c3MmcXVvdDsgPT0gUnVz cyBXaGl0ZSAmbHQ7cnVzc0BjaXNjby5jb20mZ3Q7DQp3cml0ZXM6PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgUnVzcyZndDsgU28gbXkgc2Vu c2UgaXMgdGhhdCBkaXZpZGluZyB0aGUgcmVhY2hhYmlsaXR5DQpjb250cm9sIHBsYW5lPGJyPg0K Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyBSdXNzJmd0OyBmcm9tIHRoZSBlbmNyeXB0aW9uIGNvbnRy b2wgcGxhbmUgaXMgYQ0KJnF1b3Q7Z29vZCB0aGluZywmcXVvdDsgbGlrZWx5IHRvPGJyPg0KJmd0 OyZndDsgJm5ic3A7ICZuYnNwOyBSdXNzJmd0OyByZXN1bHQgaW4gZmV3ZXIgcG9vcmx5IHVuZGVy c3Rvb2QgZmVlZGJhY2sNCmxvb3BzLCBhbmQgZmV3ZXI8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5i c3A7IFJ1c3MmZ3Q7IHVuaW50ZW5kZWQgY29uc2VxdWVuY2VzLiBJJ20gcHJldHR5IHN0cm9uZ2x5 DQppbiBmYXZvciBvZjxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgUnVzcyZndDsgc3BsaXR0 aW5nIHRoZXNlIHdoZXJlIHBvc3NpYmxlLCBhbmQgbWFraW5nDQp0aGUgQVBJIGJldHdlZW4gYXM8 YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IFJ1c3MmZ3Q7IHRyYW5zcGFyZW50IGFzIHBvc3Np YmxlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyBSdXNzJmd0OyBC dXQgSSdtIHdpbGxpbmcgdG8gaGVhciBhcmd1bWVudHMgdG8gdGhlDQpjb250cmFyeS4gJm5ic3A7 PT08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFJ1c3MsIEkgdGhpbmsgdGhlcmUgaXMgY29u c2Vuc3VzIG9uIHRoZSByZXF1aXJlbWVudCBjdXJyZW50bHkNCmluIHRoZTxicj4NCiZndDsmZ3Q7 IGRvY3VtZW50LiAmbmJzcDtJIGRvbid0IHRoaW5rIHRoZSBjb21wZWxsaW5nIGFyZ3VtZW50cyBh cmUgYWJvdXQNCndoYXQgdGhlPGJyPg0KJmd0OyZndDsgcmlnaHQgdGhpbmcgdG8gZG8gaXM6bSB5 IHBlcnNvbmFsIG9waW5pb24gaXMgdGhhdCB0aGUgcmVxdWlyZW1lbnQNCmlzIG5vdDxicj4NCiZn dDsmZ3Q7IHRoZSBiZXN0IHRlY2huaWNhbCBhcHByb2FjaCwgYnV0IHRoYXQgdGhpcyBzcGxpdCBp cyBub3QgbmVhcmx5DQphcyBiYWQgb2Y8YnI+DQomZ3Q7Jmd0OyBhIHRoaW5nIGFzIEkgYXQgZmly c3QgdGhvdWdodCBpdCB3YXMgd2hlbiBJIHN0YXJ0ZWQgdGhpbmtpbmcgYWJvdXQNCktBUlAuPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBIb3dldmVyIHBlb3BsZSBoYXZlIG1hZGUgY2xhaW1z IHRoYXQgdGhvc2UgZG9pbmcgdGhlIGltcGxlbWVudGF0aW9uDQp3b3JrPGJyPg0KJmd0OyZndDsg aW4gdGhpcyBzcGFjZSBzdHJvbmdseSBwcmVmZXIgdGhlIHNwbGl0IGFuZCB0aGF0IGFkb3B0aW5n IGEgcmVxdWlyZW1lbnQ8YnI+DQomZ3Q7Jmd0OyBmb3IgdGhpcyBzcGxpdCB3aWxsIG1ha2UgaXQg bW9yZSBsaWtlbHkgdG8gc3VjY2VlZC4gJm5ic3A7SSBkb24ndA0KdGhpbmsgdGhhdDxicj4NCiZn dDsmZ3Q7IHN1Y2ggYSBzcGxpdCBpcyBiYWQgZW5vdWdoIG9uIGEgdGVjaG5pY2FsIGZyb250IHRo YXQgd2Ugc2hvdWxkDQpydWxlIGl0PGJyPg0KJmd0OyZndDsgb3V0LiBTbywgaWYgdGhlIHNwbGl0 IGdldHMgdXMgaW1wbGVtZW50YXRpb25zIGFuZCB0aGUgbGFjayBvZg0KYSBzcGxpdDxicj4NCiZn dDsmZ3Q7IGdldHMgdXMgaXJyZWxldmFuY2UsIGxldCdzIGdvIHdpdGggdGhlIHJlcXVpcmVtZW50 Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgU28sIG15IHF1ZXN0aW9uIHRvIHRoZSBXRyBh cyBhIHdob2xlIGlzIGRvIHdlIGFjdHVhbGx5IHdhbnQgdG8NCmhhdmU8YnI+DQomZ3Q7Jmd0OyBh bm90aGVyIHJvdW5kIG9mIGRpc2N1c3Npb24gb24gd2hldGhlciBSdXNzJ3MgdGVjaG5pY2FsIGFy Z3VtZW50DQphYm92ZTxicj4NCiZndDsmZ3Q7IGlzIGNvcnJlY3Q/IE9yIGFyZSB3ZSB3aWxsaW5n IHRvIGFjY2VwdCB0aGlzIHJlcXVpcmVtZW50IGFzIGENCnByYWN0aWNhbDxicj4NCiZndDsmZ3Q7 IG5lY2Vzc2l0eT8gTXkgcGVyc29uYWwgb3BpbmlvbiBpcyB0aGF0IHRoaXMgcmVxdWlyZW1lbnQg aXMgbm90DQphPGJyPg0KJmd0OyZndDsgdGVjaG5pY2FsIGlzc3VlIGFuZCBzbyBoYXZpbmcgdGhp cyBhcyBhIHRlY2huaWNhbCBkaXNjdXNzaW9uIGlzDQpub3QgYW48YnI+DQomZ3Q7Jmd0OyBlZmZl Y3RpdmUgc3RyYXRlZ3kuIEkgZmVlbCBzdHJvbmdseSB0aGF0IHdlIHNob3VsZCBtYWtlIGZvcndh cmQNCnByb2dyZXNzPGJyPg0KJmd0OyZndDsgYW5kIGRvIG5vdCBmZWVsIHRoYXQgc3Ryb25nbHkg YWJvdXQgd2hldGhlciB0aGlzIHJlcXVpcmVtZW50IHNob3VsZA0KYmU8YnI+DQomZ3Q7Jmd0OyBw cmVzZW50Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhhdCBzYWlkLCBpZiBwZW9wbGUg d2FudCB0byBoYXZlIHRoZSB0ZWNobmljYWwgZGlzY3Vzc2lvbiBJJ20NCmhhcHB5IHRvPGJyPg0K Jmd0OyZndDsgam9pbiBpdCBvbiB0aGUgbGlzdCBvciBpbiBwcml2YXRlLjxicj4NCiZndDs8YnI+ DQomZ3Q7IEkgdGhvdWdodCB0aGVyZSBoYWQgYWxyZWFkeSBiZWVuIGEgZ29vZCBkaXNjdXNzaW9u IG9mIHRoaXMgcG9pbnQgYW5kDQp0aG91Z2h0PGJyPg0KJmd0OyBpdCBoYWQgYmVlbiBjbG9zZWQu IEknbSBoYXBweSB3aXRoIHRoZSByZXF1aXJlbWVudCBhcyBpdCBpcyB3cml0dGVuLjxicj4NCiZn dDs8YnI+DQomZ3Q7IC1NaWNoYWVsPGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGthcnAgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyBrYXJwQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2thcnA8YnI+DQomZ3Q7PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQprYXJwIG1haWxpbmcgbGlzdDxicj4N CmthcnBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2thcnA8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNw O0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5m b3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7 aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVy J3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0 aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVk Jm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWlu Jm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZu YnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7 dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtl bWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3 aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRl bmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9t Jm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNw O2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJy b3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVz c2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21l c3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVz ZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJz cDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0029552E4825781D_=-- From liang.xiaoping@zte.com.cn Wed Jan 19 00:20: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 7B3EA3A6F90; Wed, 19 Jan 2011 00:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.648 X-Spam-Level: X-Spam-Status: No, score=-96.648 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 tSOjkfqYU40e; Wed, 19 Jan 2011 00:20:09 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 531113A6DA4; Wed, 19 Jan 2011 00:20:01 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35102175658078; Wed, 19 Jan 2011 16:20:18 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 96520.3208842533; Wed, 19 Jan 2011 16:22:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p0J8MQ0O078098; Wed, 19 Jan 2011 16:22:26 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: To: Sam Hartman MIME-Version: 1.0 X-KeepSent: 8739581A:A4E571AD-4825781D:002A8967; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Wed, 19 Jan 2011 16:22:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-19 16:22:28, Serialize complete at 2011-01-19 16:22:28 Content-Type: multipart/alternative; boundary="=_alternative 002DFEF84825781D_=" X-MAIL: mse02.zte.com.cn p0J8MQ0O078098 Cc: karp-bounces@ietf.org, karp@ietf.org Subject: Re: [karp] Negotiation 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, 19 Jan 2011 08:20:10 -0000 This is a multipart message in MIME format. --=_alternative 002DFEF84825781D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2FtLA0KDQpXZWxjb21lIHRoZSBkaXNjdXNzaW9uIG9uIG5lZ290aWF0aW9uISBWZXJ5IGFw cHJlY2lhdGVkIF5fXg0KDQpJdCBpcyBtZSB0aGF0IGRpZCB0aGUgcHJlc2VudGF0aW9uIG9uIHNp dGUgYW5kIGFza2VkIGZvciBuZWdvdGlhdGlvbiBkdWUgDQp0byB0aGUgcmVxdWlyZW1lbnQgZm9y IGFsZ29yaXRobSBhZ2lsaXR5LiBNeSBuYW1lIGlzIFhpYW9waW5nIExpYW5nLCBtYXkgDQpiZSBh IGJpdCBjb21wbGV4IHRvIHlvdSwgYW5kIHlvdSBtYXkgY2FsbCBtZSBFbGxlbiBeX14NCg0KV2hh dCB5b3UgcG9pbnRlZCBvdXQgaW4gdGhlIGVtYWlsIGlzIHZlcnkgaW1wb3J0bWVudCwgYW5kIG5l Z290aWF0aW9uIA0KZGlyZWN0bHkgZm9yIHJvdXRlcnMgaW4gY3VycmVudCB1c2Ugd2l0aG91dCBt b3JlIHdvcmsgd2lsbCBETyBpbnRyb2R1Y2UgDQpyaXNrcywgYW5kIGV2ZW4gYnJpbmcgb3V0IHNl dmVyZSBjb25zZXF1ZW5jZXMuIEJ1dCB3aXRob3V0IG5lZ290aWF0aW9uLCBpdCANCmlzIHZlcnkg ZGlmZmljdWxlIHRvIGFjaGlldmUgYmV0dGVyIHNlY3VyaXR5IGFuZCBiZXR0ZXIgDQppbnRlcm9w ZXJhdGlvbi9pbnRlcmNvbm5lY3Rpb24uIFllcywgSSBkbyBhZ3JlZSwgYXMgZW5naW5lZXIsIG91 ciBqb2IgaXMgDQp0byBiYWxhbmNlIHRoZXNlIHRyYWRlb2Zmcy4gQW5kIHdlIG5lZWQgdG8gZG8g TU9SRSB3b3JrIHRvIG1ha2UgDQpuZWdvdGlhdGlvbiBsZXNzIHJpc2t5IGJlc2lkZXMgY29uZmln dXJhdGlvbi4gDQoNClRoZSB1bndhbnRlZCBjb25zZXF1ZW5jZXMgeW91IHBvaW50ZWQgb3V0IHdo ZW4gdXNpbmcgbmVnb3RpYXRpb24gY29tZSBmcm9tIA0KaW1wbGVtZW50YXRpb24gYW5kIGRlcGxv eW1lbnRzIG9mIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyBvciBzZWN1cml0eSANCm1lY2hhbmlz bXMgaW4gdGhlIHJvdXRlcnMuIEkgdGhpbmsgdGhlIHByb2JsZW0gd2lsbCBiZSBzb2x2ZWQgZmlu YWxseS4NCg0KQ2hlZXJzLA0KRWxsZW4gKFhpYW9waW5nIExpYW5nKQ0KIA0KDQoNCg0KU2FtIEhh cnRtYW4gPGhhcnRtYW5zLWlldGZAbWl0LmVkdT4gDQq3orz+yMs6ICBrYXJwLWJvdW5jZXNAaWV0 Zi5vcmcNCjIwMTEtMDEtMTQgMDA6MDMNCg0KytW8/sjLDQprYXJwQGlldGYub3JnDQqzrcvNDQoN Ctb3zOINCltrYXJwXSBOZWdvdGlhdGlvbg0KDQoNCg0KDQoNCg0KQXQgdGhlIGxhc3QgbWVldGlu ZywgWWlueGluZyBXZWkgYXNrZWQgYWJvdXQgb3VyIHN0cmF0ZWd5IGZvcg0KbmVnb3RpYXRpb24g b2YgY3J5cHRvZ3JhcGhpYyBwYXJhbWV0ZXJzLg0KDQpJIHRoaW5rIHRoaXMgaXMgYW4gaW1wb3J0 YW50IGRpc2N1c3Npb24gdG8gaGF2ZS4gIEl0J3MgYW5vdGhlciBhcmVhDQp3aGVyZSBJIHRoaW5r IHdlIG1heSBmaW5kIHRoZSBzZWN1cml0eSBhcmVhJ3MgZGVmYXVsdCBhc3N1bXB0aW9ucyBkaWZm ZXINCmZyb20gdGhlIHJvdXRpbmcgYXJlYS4NCg0KSSBkb24ndCBoYXZlIHN0cm9uZyBvcGluaW9u cyBvbiB3aGF0IHRoZSBhbnN3ZXIgaXMsIHNvIHBlcmhhcHMgSSBjYW4gdHJ5DQphbmQgb3V0bGlu ZSBib3RoIHNpZGVzIGFzIEkgdW5kZXJzdGFuZCB0aGVtLiAgUGVyaGFwcyB0aGlzIHdpbGwgaGVs cCBnZXQNCnRoaW5ncyBzdGFydGVkLg0KDQpSb3V0aW5nIHByb3RvY29scyBoYXZlIGEgZmFpciBi aXQgb2YgY29uZmlndXJhdGlvbi4gRm9yIEJHUCwgeW91IG5lZWQgdG8NCmNvbmZpZ3VyZSBwZWVy cywgQVMgaW5mb3JtYXRpb24gYW5kIGEgaGVjayBvZiBhIGxvdCBvZiBwb2xpY3kuIEV2ZW4gZm9y DQpzb21ldGhpbmcgbGlrZSBPU1BGIGFuZCBJUy1JUyB0aGF0IHRyeSB0byBoYXZlIGEgZmFpciBi aXQgb2YgYXV0b21hdGVkDQpkaXNjb3ZlcnksIHlvdSBuZWVkIHRvIGluZGljYXRlIHdoYXQgYXJl YSBhbiBpbnRlcmZhY2UgaXMgaW4uIFRoaXMNCmNvbmZpZ3VyYXRpb24gbmVlZHMgdG8gYmUgY29u c2lzdGVudCBhbmQgc3luY2hyb25pemVkLiBBcyBhIHJlc3VsdCwNCmFueW9uZSB3aG8gaGFzIG1v cmUgdGhhbiBhIGNvdXBsZSBvZiByb3V0ZXJzIGhhcyBtZWNoYW5pc21zIGZvciBtYW5hZ2luZw0K YW5kIHVwZGF0aW5nIGNvbmZpZ3VyYXRpb24uIFVwZGF0aW5nIHdoYXQgY3J5cHRvZ3JhcGhpYyBh bGdvcml0aG1zIHRvDQp1c2UgaW4gYSBjb25maWd1cmF0aW9uIGlzIG5vdCB0aGF0IGRpZmZpY3Vs dC4NCg0KT25lIGhpZ2hseSB1bmRlc2lyYWJsZSB0aGluZyBpbiBhbiBvcGVyYXRpb25hbCBuZXR3 b3JrIGlzIHdoZW4gc29tZQ0KY2hhbmdlIGhhcyB1bmV4cGVjdGVkIGNvbnNlcXVlbmNlcy4gSGVy ZSBhcmUgYSBjb3VwbGUgb2Ygc2l0dWF0aW9ucyB0aGF0DQptaWdodCBoZWxwIHVuZGVyc3RhbmQg d2h5IGFuIG9wZXJhdG9yIGlzIG5lcnZvdXMgYWJvdXQgbmVnb3RpYXRpb24uIFR3bw0KcGVlcnMg KEEgYW5kIEIpIG5lZ290aWF0ZSBjcnlwdG9ncmFwaGljIGF1dGhlbnRpY2F0aW9uLiBCZWZvcmUg YW4NCnVwZ3JhZGUsIGV2ZXJ5dGhpbmcgaXMgd29ya2luZy4gQiBzdXBwb3J0cyBTSEEtMSBhbmQg U0hBLTI1NiwgYnV0IEEgb25seQ0Kc3VwcG9ydHMgU0hBLTEuIEEgaXMgdXBncmFkZWQgYW5kIG5v dyBzdXBwb3J0cyBTSEEtMjU2LiBVbmZvcnR1bmF0ZWx5LA0KQidzIGltcGxlbWVudGF0aW9uIG9m IHRoZSByb3V0aW5nIGF1dGhlbnRpY2F0aW9uIHVzaW5nIFNIQS0yNTYgaXMNCmJ1Z2d5LiBUaGUg dXBncmFkZSBjYXVzZXMgdGhpbmdzIHRvIGJyZWFrLiAgUGVyaGFwcyB5b3UnbGwgYXJndWUgdGhh dCdzDQpub3QgcmVhbGx5IGFuIHVuaW50ZW5kZWQgY29uc2VxdWVuY2U6IHVwZ3JhZGVzIHNvbWV0 aW1lcyBleHBvc2UgYnVncyBpbg0KdGhlIHN5c3RlbXMgaW52b2x2ZWQgaW4gdGhlIHVwZ3JhZGUu DQoNCkhvd2V2ZXIsIG5lZ290aWF0aW9uIGNhbiBtYWtlIHByb2JsZW1zIGZhciBtb3JlIGhpZGRl bi4gQ29uc2lkZXIgYQ0KbmV0d29yayB3aXRoIHJvdXRlcnMgQSwgQiBhbmQgQy4gQiBhbmQgQyBz dXBwb3J0IFNIQS0yNTYgYW5kIFNIQS0xLCBidXQNCkEgY3VycmVudGx5IG9ubHkgc3VwcG9ydHMg U0hBLTEuIFNvbWUgcHJvdG9jb2wgd2l0aCBhIGdyb3VwIGtleSBpcw0KaW4tdXNlLiBBIGlzIHVw Z3JhZGVkOyBhcyBhIHJlc3VsdCB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIEIgYW5kIEMNCmhh cHBlbnMuIFRoaXMgY2FuIGJlIHRoZSBjYXNlIGlmIEMncyBpbXBsZW1lbnRhdGlvbiBvZiBTSEEt MjU2IGRvZXMgbm90DQp3b3JrIHdpdGggQi4gU28sIGV2ZW4gdGhvdWdoIG5laXRoZXIgb2YgdGhl IHBhcnRpZXMgZGlyZWN0bHkgaW52b2x2ZWQgaW4NCnRoZSBjb21tdW5pY2F0aW9uIGNoYW5nZWQg c29mdHdhcmUgb3IgY29uZmlndXJhdGlvbiwgdGhlIHNldCBvZg0KY2FwYWJpbGl0aWVzIG9uIHRo ZSBuZXR3b3JrIGNoYW5nZWQsIHdoaWNoIGNoYW5nZXMgd2hhdCBpcyB1c2VkLg0KDQpPbiB0aGUg b3RoZXIgaGFuZCwgbmVnb3RpYXRpb24gaW4gc2VjdXJpdHkgcHJvdG9jb2xzIGlzIHVzZWZ1bC4g VXNlcnMNCmRvbid0IHRlbmQgdG8gdXBkYXRlIGNvbmZpZ3VyYXRpb25zLiBBbHNvLCB0aGUgbW9y ZSB5b3UgaGF2ZSB0bw0KY29uZmlndXJlLCB0aGUgaGFyZGVyIGl0IGlzIHRvIGdldCBzZWN1cml0 eSB3b3JraW5nLiBJZiBzZWN1cml0eQ0KcGFyYW1ldGVycyBjYW4gYmUgZGV0ZXJtaW5lZCBhdXRv bWF0aWNhbGx5IHdpdGhvdXQgY29tcHJvbWlzaW5nDQpzZWN1cml0eSwgdXNhYmlsaXR5IGlzIGlu Y3JlYXNlZC4gTmVnb3RpYXRpb24gd2lsbCBsZWFkIHRvIHRoZSBncmFkdWFsDQpkZXBsb3ltZW50 IG9mIGJldHRlciBwcm90b2NvbHMgYXMgc29mdHdhcmUgaXMgdXBkYXRlZC4gU28sIG5lZ290aWF0 aW9uDQppcyBkZXNpcmFibGUuDQoNCk91ciBqb2IgaXMgdG8gYmFsYW5jZSB0aGVzZSB0cmFkZW9m ZnMuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Ka2Fy cCBtYWlsaW5nIGxpc3QNCmthcnBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8va2FycA0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJv cGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRp b24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQg dG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhl IGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFu ZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo b20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2 aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVh bCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQg U3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 002DFEF84825781D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBTYW0sPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5XZWxjb21lIHRoZSBkaXNjdXNzaW9uIG9uIG5lZ290aWF0aW9uISBWZXJ5 IGFwcHJlY2lhdGVkDQpeX148L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y Pkl0IGlzIG1lIHRoYXQgZGlkIHRoZSBwcmVzZW50YXRpb24gb24gc2l0ZSBhbmQgYXNrZWQNCmZv ciBuZWdvdGlhdGlvbiBkdWUgdG8gdGhlIHJlcXVpcmVtZW50IGZvciBhbGdvcml0aG0gYWdpbGl0 eS4gTXkgbmFtZSBpcw0KWGlhb3BpbmcgTGlhbmcsIG1heSBiZSBhIGJpdCBjb21wbGV4IHRvIHlv dSwgYW5kIHlvdSBtYXkgY2FsbCBtZSBFbGxlbg0KXl9ePC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5XaGF0IHlvdSBwb2ludGVkIG91dCBpbiB0aGUgZW1haWwgaXMgdmVy eSBpbXBvcnRtZW50LA0KYW5kIG5lZ290aWF0aW9uIGRpcmVjdGx5IGZvciByb3V0ZXJzIGluIGN1 cnJlbnQgdXNlIHdpdGhvdXQgbW9yZSB3b3JrIHdpbGwNCkRPIGludHJvZHVjZSByaXNrcywgYW5k IGV2ZW4gYnJpbmcgb3V0IHNldmVyZSBjb25zZXF1ZW5jZXMuIEJ1dCB3aXRob3V0DQpuZWdvdGlh dGlvbiwgaXQgaXMgdmVyeSBkaWZmaWN1bGUgdG8gYWNoaWV2ZSBiZXR0ZXIgc2VjdXJpdHkgYW5k IGJldHRlcg0KaW50ZXJvcGVyYXRpb24vaW50ZXJjb25uZWN0aW9uLiBZZXMsIEkgZG8gYWdyZWUs IGFzIGVuZ2luZWVyLCBvdXIgam9iIGlzDQp0byBiYWxhbmNlIHRoZXNlIHRyYWRlb2Zmcy4gQW5k IHdlIG5lZWQgdG8gZG8gTU9SRSB3b3JrIHRvIG1ha2UgbmVnb3RpYXRpb24NCmxlc3Mgcmlza3kg YmVzaWRlcyBjb25maWd1cmF0aW9uLiA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPlRoZSB1bndhbnRlZCBjb25zZXF1ZW5jZXMgeW91IHBvaW50ZWQgb3V0IHdoZW4gdXNp bmcNCm5lZ290aWF0aW9uIGNvbWUgZnJvbSBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudHMg b2YgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zDQpvciBzZWN1cml0eSBtZWNoYW5pc21zIGluIHRo ZSByb3V0ZXJzLiBJIHRoaW5rIHRoZSBwcm9ibGVtIHdpbGwgYmUgc29sdmVkDQpmaW5hbGx5Ljwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Q2hlZXJzLDwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+RWxsZW4gKFhpYW9waW5nIExpYW5nKTwvZm9udD48L3R0 Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0z NSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlNhbSBIYXJ0bWFuICZsdDtoYXJ0 bWFucy1pZXRmQG1pdC5lZHUmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO2thcnAtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTAxLTE0IDAwOjAzPC9mb250 Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+ yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmthcnBA aWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPltrYXJwXSBOZWdvdGlhdGlvbjwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJy Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QXQgdGhlIGxhc3QgbWVldGluZywgWWlueGlu ZyBXZWkgYXNrZWQgYWJvdXQgb3VyIHN0cmF0ZWd5DQpmb3I8YnI+DQpuZWdvdGlhdGlvbiBvZiBj cnlwdG9ncmFwaGljIHBhcmFtZXRlcnMuPGJyPg0KPGJyPg0KSSB0aGluayB0aGlzIGlzIGFuIGlt cG9ydGFudCBkaXNjdXNzaW9uIHRvIGhhdmUuICZuYnNwO0l0J3MgYW5vdGhlciBhcmVhPGJyPg0K d2hlcmUgSSB0aGluayB3ZSBtYXkgZmluZCB0aGUgc2VjdXJpdHkgYXJlYSdzIGRlZmF1bHQgYXNz dW1wdGlvbnMgZGlmZmVyPGJyPg0KZnJvbSB0aGUgcm91dGluZyBhcmVhLjxicj4NCjxicj4NCkkg ZG9uJ3QgaGF2ZSBzdHJvbmcgb3BpbmlvbnMgb24gd2hhdCB0aGUgYW5zd2VyIGlzLCBzbyBwZXJo YXBzIEkgY2FuIHRyeTxicj4NCmFuZCBvdXRsaW5lIGJvdGggc2lkZXMgYXMgSSB1bmRlcnN0YW5k IHRoZW0uICZuYnNwO1BlcmhhcHMgdGhpcyB3aWxsIGhlbHANCmdldDxicj4NCnRoaW5ncyBzdGFy dGVkLjxicj4NCjxicj4NClJvdXRpbmcgcHJvdG9jb2xzIGhhdmUgYSBmYWlyIGJpdCBvZiBjb25m aWd1cmF0aW9uLiBGb3IgQkdQLCB5b3UgbmVlZCB0bzxicj4NCmNvbmZpZ3VyZSBwZWVycywgQVMg aW5mb3JtYXRpb24gYW5kIGEgaGVjayBvZiBhIGxvdCBvZiBwb2xpY3kuIEV2ZW4gZm9yPGJyPg0K c29tZXRoaW5nIGxpa2UgT1NQRiBhbmQgSVMtSVMgdGhhdCB0cnkgdG8gaGF2ZSBhIGZhaXIgYml0 IG9mIGF1dG9tYXRlZDxicj4NCmRpc2NvdmVyeSwgeW91IG5lZWQgdG8gaW5kaWNhdGUgd2hhdCBh cmVhIGFuIGludGVyZmFjZSBpcyBpbi4gVGhpczxicj4NCmNvbmZpZ3VyYXRpb24gbmVlZHMgdG8g YmUgY29uc2lzdGVudCBhbmQgc3luY2hyb25pemVkLiBBcyBhIHJlc3VsdCw8YnI+DQphbnlvbmUg d2hvIGhhcyBtb3JlIHRoYW4gYSBjb3VwbGUgb2Ygcm91dGVycyBoYXMgbWVjaGFuaXNtcyBmb3Ig bWFuYWdpbmc8YnI+DQphbmQgdXBkYXRpbmcgY29uZmlndXJhdGlvbi4gVXBkYXRpbmcgd2hhdCBj cnlwdG9ncmFwaGljIGFsZ29yaXRobXMgdG88YnI+DQp1c2UgaW4gYSBjb25maWd1cmF0aW9uIGlz IG5vdCB0aGF0IGRpZmZpY3VsdC48YnI+DQo8YnI+DQpPbmUgaGlnaGx5IHVuZGVzaXJhYmxlIHRo aW5nIGluIGFuIG9wZXJhdGlvbmFsIG5ldHdvcmsgaXMgd2hlbiBzb21lPGJyPg0KY2hhbmdlIGhh cyB1bmV4cGVjdGVkIGNvbnNlcXVlbmNlcy4gSGVyZSBhcmUgYSBjb3VwbGUgb2Ygc2l0dWF0aW9u cyB0aGF0PGJyPg0KbWlnaHQgaGVscCB1bmRlcnN0YW5kIHdoeSBhbiBvcGVyYXRvciBpcyBuZXJ2 b3VzIGFib3V0IG5lZ290aWF0aW9uLiBUd288YnI+DQpwZWVycyAoQSBhbmQgQikgbmVnb3RpYXRl IGNyeXB0b2dyYXBoaWMgYXV0aGVudGljYXRpb24uIEJlZm9yZSBhbjxicj4NCnVwZ3JhZGUsIGV2 ZXJ5dGhpbmcgaXMgd29ya2luZy4gQiBzdXBwb3J0cyBTSEEtMSBhbmQgU0hBLTI1NiwgYnV0IEEg b25seTxicj4NCnN1cHBvcnRzIFNIQS0xLiBBIGlzIHVwZ3JhZGVkIGFuZCBub3cgc3VwcG9ydHMg U0hBLTI1Ni4gVW5mb3J0dW5hdGVseSw8YnI+DQpCJ3MgaW1wbGVtZW50YXRpb24gb2YgdGhlIHJv dXRpbmcgYXV0aGVudGljYXRpb24gdXNpbmcgU0hBLTI1NiBpczxicj4NCmJ1Z2d5LiBUaGUgdXBn cmFkZSBjYXVzZXMgdGhpbmdzIHRvIGJyZWFrLiAmbmJzcDtQZXJoYXBzIHlvdSdsbCBhcmd1ZSB0 aGF0J3M8YnI+DQpub3QgcmVhbGx5IGFuIHVuaW50ZW5kZWQgY29uc2VxdWVuY2U6IHVwZ3JhZGVz IHNvbWV0aW1lcyBleHBvc2UgYnVncyBpbjxicj4NCnRoZSBzeXN0ZW1zIGludm9sdmVkIGluIHRo ZSB1cGdyYWRlLjxicj4NCjxicj4NCkhvd2V2ZXIsIG5lZ290aWF0aW9uIGNhbiBtYWtlIHByb2Js ZW1zIGZhciBtb3JlIGhpZGRlbi4gQ29uc2lkZXIgYTxicj4NCm5ldHdvcmsgd2l0aCByb3V0ZXJz IEEsIEIgYW5kIEMuIEIgYW5kIEMgc3VwcG9ydCBTSEEtMjU2IGFuZCBTSEEtMSwgYnV0PGJyPg0K QSBjdXJyZW50bHkgb25seSBzdXBwb3J0cyBTSEEtMS4gU29tZSBwcm90b2NvbCB3aXRoIGEgZ3Jv dXAga2V5IGlzPGJyPg0KaW4tdXNlLiBBIGlzIHVwZ3JhZGVkOyBhcyBhIHJlc3VsdCB0aGUgY29t bXVuaWNhdGlvbiBiZXR3ZWVuIEIgYW5kIEM8YnI+DQpoYXBwZW5zLiBUaGlzIGNhbiBiZSB0aGUg Y2FzZSBpZiBDJ3MgaW1wbGVtZW50YXRpb24gb2YgU0hBLTI1NiBkb2VzIG5vdDxicj4NCndvcmsg d2l0aCBCLiBTbywgZXZlbiB0aG91Z2ggbmVpdGhlciBvZiB0aGUgcGFydGllcyBkaXJlY3RseSBp bnZvbHZlZCBpbjxicj4NCnRoZSBjb21tdW5pY2F0aW9uIGNoYW5nZWQgc29mdHdhcmUgb3IgY29u ZmlndXJhdGlvbiwgdGhlIHNldCBvZjxicj4NCmNhcGFiaWxpdGllcyBvbiB0aGUgbmV0d29yayBj aGFuZ2VkLCB3aGljaCBjaGFuZ2VzIHdoYXQgaXMgdXNlZC48YnI+DQo8YnI+DQpPbiB0aGUgb3Ro ZXIgaGFuZCwgbmVnb3RpYXRpb24gaW4gc2VjdXJpdHkgcHJvdG9jb2xzIGlzIHVzZWZ1bC4gVXNl cnM8YnI+DQpkb24ndCB0ZW5kIHRvIHVwZGF0ZSBjb25maWd1cmF0aW9ucy4gQWxzbywgdGhlIG1v cmUgeW91IGhhdmUgdG88YnI+DQpjb25maWd1cmUsIHRoZSBoYXJkZXIgaXQgaXMgdG8gZ2V0IHNl Y3VyaXR5IHdvcmtpbmcuIElmIHNlY3VyaXR5PGJyPg0KcGFyYW1ldGVycyBjYW4gYmUgZGV0ZXJt aW5lZCBhdXRvbWF0aWNhbGx5IHdpdGhvdXQgY29tcHJvbWlzaW5nPGJyPg0Kc2VjdXJpdHksIHVz YWJpbGl0eSBpcyBpbmNyZWFzZWQuIE5lZ290aWF0aW9uIHdpbGwgbGVhZCB0byB0aGUgZ3JhZHVh bDxicj4NCmRlcGxveW1lbnQgb2YgYmV0dGVyIHByb3RvY29scyBhcyBzb2Z0d2FyZSBpcyB1cGRh dGVkLiBTbywgbmVnb3RpYXRpb248YnI+DQppcyBkZXNpcmFibGUuPGJyPg0KPGJyPg0KT3VyIGpv YiBpcyB0byBiYWxhbmNlIHRoZXNlIHRyYWRlb2Zmcy48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmthcnAgbWFpbGluZyBsaXN0PGJyPg0K a2FycEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v a2FycDxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7 SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZv cm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtp cyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIn cyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRp b24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQm bmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4m bmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5i c3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0 aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2Vt YWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dp dGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVu ZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20m bmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7 aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJv ciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNz ZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJz cDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVz c2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNl cyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNw O3N5c3RlbS4NCjwvcHJlPg== --=_alternative 002DFEF84825781D_=-- From liang.xiaoping@zte.com.cn Wed Jan 19 00:24:03 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 4B4233A70DF; Wed, 19 Jan 2011 00:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.38 X-Spam-Level: X-Spam-Status: No, score=-96.38 tagged_above=-999 required=5 tests=[AWL=1.255, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 yQVACB9cqozN; Wed, 19 Jan 2011 00:24:02 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 344F53A6D05; Wed, 19 Jan 2011 00:24:01 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205952175658078; Wed, 19 Jan 2011 16:21:50 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 96520.5162356210; Wed, 19 Jan 2011 16:26:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p0J8QRGG083592; Wed, 19 Jan 2011 16:26:27 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: <066Pamqpr7616S01.1294936963@web01.cms.usa.net> To: "Michael Barnes" MIME-Version: 1.0 X-KeepSent: 4A72011B:82408282-4825781D:002E38FE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Wed, 19 Jan 2011 16:26:32 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-19 16:26:30, Serialize complete at 2011-01-19 16:26:30 Content-Type: multipart/alternative; boundary="=_alternative 002E5D424825781D_=" X-MAIL: mse02.zte.com.cn p0J8QRGG083592 Cc: karp-bounces@ietf.org, Sam Hartman , karp@ietf.org Subject: Re: [karp] Negotiation 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, 19 Jan 2011 08:24:03 -0000 This is a multipart message in MIME format. --=_alternative 002E5D424825781D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTWljaGFlbCwNCg0KSSBkbyBhZ3JlZSB3aXRoIHlvdS4NCg0KQ2hlZXJzLA0KRWxsZW4gKFhp YW9waW5nIExpYW5nKQ0KIA0KDQoNCg0KIk1pY2hhZWwgQmFybmVzIiA8bWljaGFlbF9iYXJuZXNA dXNhLm5ldD4gDQq3orz+yMs6ICBrYXJwLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDEtMTQgMDA6 NDINCg0KytW8/sjLDQpTYW0gSGFydG1hbiA8aGFydG1hbnMtaWV0ZkBtaXQuZWR1Pg0Ks63LzQ0K a2FycEBpZXRmLm9yZw0K1vfM4g0KUmU6IFtrYXJwXSBOZWdvdGlhdGlvbg0KDQoNCg0KDQoNCg0K SGkgU2FtLA0KDQpJIHRoaW5rIHRoZXJlIGFyZSBtYW55IHdheXMgaW4gd2hpY2ggYXV0byBuZWdv dGlhdGlvbiBjYW4gYmVuZWZpdCB1c2VycyANCmFuZA0KaG9wZSB3ZSBjYW4gd29yayB0aHJvdWdo IGNvbmNlcm5zLiBDb25maWd1cmF0aW9uIGNvbXBsZXhpdHkgaXMgb25lIHJlYXNvbiANCnRoYXQN Cm9wZXJhdG9ycyBkb24ndCB1c2Ugc29waGlzdGljYXRlZCBzZWN1cml0eSwgc28gcmVkdWNpbmcg dGhlIGNvbmZpZ3VyYXRpb24NCmVmZm9ydCBzaG91bGQgaW5jcmVhc2UgZGVwbG95bWVudHMuDQoN Ckkgc3VnZ2VzdCB0aGF0IGEgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGJlIGF2YWlsYWJsZSBidXQg ZGVzaWduZWQgc28gdGhhdCBhDQp1c2VyIGNhbiBjb250cm9sIGl0LCBvciBldmVuIGRpc2FibGUg aXQsIHRocm91Z2ggY29uZmlndXJhdGlvbi4gVGhpcyB3YXkgDQppZiBhDQp1c2VyIGhhcyBzb21l IHJlYXNvbiB0byBiZSBjb25jZXJuZWQgdGhhdCB0aGUgbmVnb3RpYXRpb24gbWVjaGFuaXNtIHdv bid0IA0Kd29yaw0KY29ycmVjdGx5IG9yIHNvbWUgaXNzdWVzIG1pZ2h0IGJlIGludHJvZHVjZWQg YnkgdXNpbmcgc3VjaCBhIG1lY2hhbmlzbSwgDQpmb3INCmV4YW1wbGUgaWYgdGhleSBhcmUgdXNp bmcgZGV2aWNlcyBmcm9tIG11bHRpcGxlIHZlbmRvcnMgYW5kIGRvbid0IHRydXN0IA0KdGhvc2UN CmRldmljZXMgdG8gYmUgaW50ZXJvcGVyYWJsZSwgdGhlbiB0aGUgb3BlcmF0b3IgY2FuIGNhcmVm dWxseSBjb250cm9sIHRoZQ0KYXV0aGVudGljYXRpb24gcGFyYW1ldGVycy4NCg0KUmVnYXJkcywN Ck1pY2hhZWwNCg0KLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tDQpSZWNlaXZlZDogVGh1 LCAxMyBKYW4gMjAxMSAwODowMzozNSBBTSBQU1QNCkZyb206IFNhbSBIYXJ0bWFuIDxoYXJ0bWFu cy1pZXRmQG1pdC5lZHU+DQpUbzoga2FycEBpZXRmLm9yZw0KU3ViamVjdDogW2thcnBdIE5lZ290 aWF0aW9uDQoNCj4gQXQgdGhlIGxhc3QgbWVldGluZywgWWlueGluZyBXZWkgYXNrZWQgYWJvdXQg b3VyIHN0cmF0ZWd5IGZvcg0KPiBuZWdvdGlhdGlvbiBvZiBjcnlwdG9ncmFwaGljIHBhcmFtZXRl cnMuDQo+DQo+IEkgdGhpbmsgdGhpcyBpcyBhbiBpbXBvcnRhbnQgZGlzY3Vzc2lvbiB0byBoYXZl LiAgSXQncyBhbm90aGVyIGFyZWENCj4gd2hlcmUgSSB0aGluayB3ZSBtYXkgZmluZCB0aGUgc2Vj dXJpdHkgYXJlYSdzIGRlZmF1bHQgYXNzdW1wdGlvbnMgZGlmZmVyDQo+IGZyb20gdGhlIHJvdXRp bmcgYXJlYS4NCj4NCj4gSSBkb24ndCBoYXZlIHN0cm9uZyBvcGluaW9ucyBvbiB3aGF0IHRoZSBh bnN3ZXIgaXMsIHNvIHBlcmhhcHMgSSBjYW4gdHJ5DQo+IGFuZCBvdXRsaW5lIGJvdGggc2lkZXMg YXMgSSB1bmRlcnN0YW5kIHRoZW0uICBQZXJoYXBzIHRoaXMgd2lsbCBoZWxwIGdldA0KPiB0aGlu Z3Mgc3RhcnRlZC4NCj4NCj4gUm91dGluZyBwcm90b2NvbHMgaGF2ZSBhIGZhaXIgYml0IG9mIGNv bmZpZ3VyYXRpb24uIEZvciBCR1AsIHlvdSBuZWVkIHRvDQo+IGNvbmZpZ3VyZSBwZWVycywgQVMg aW5mb3JtYXRpb24gYW5kIGEgaGVjayBvZiBhIGxvdCBvZiBwb2xpY3kuIEV2ZW4gZm9yDQo+IHNv bWV0aGluZyBsaWtlIE9TUEYgYW5kIElTLUlTIHRoYXQgdHJ5IHRvIGhhdmUgYSBmYWlyIGJpdCBv ZiBhdXRvbWF0ZWQNCj4gZGlzY292ZXJ5LCB5b3UgbmVlZCB0byBpbmRpY2F0ZSB3aGF0IGFyZWEg YW4gaW50ZXJmYWNlIGlzIGluLiBUaGlzDQo+IGNvbmZpZ3VyYXRpb24gbmVlZHMgdG8gYmUgY29u c2lzdGVudCBhbmQgc3luY2hyb25pemVkLiBBcyBhIHJlc3VsdCwNCj4gYW55b25lIHdobyBoYXMg bW9yZSB0aGFuIGEgY291cGxlIG9mIHJvdXRlcnMgaGFzIG1lY2hhbmlzbXMgZm9yIG1hbmFnaW5n DQo+IGFuZCB1cGRhdGluZyBjb25maWd1cmF0aW9uLiBVcGRhdGluZyB3aGF0IGNyeXB0b2dyYXBo aWMgYWxnb3JpdGhtcyB0bw0KPiB1c2UgaW4gYSBjb25maWd1cmF0aW9uIGlzIG5vdCB0aGF0IGRp ZmZpY3VsdC4NCj4NCj4gT25lIGhpZ2hseSB1bmRlc2lyYWJsZSB0aGluZyBpbiBhbiBvcGVyYXRp b25hbCBuZXR3b3JrIGlzIHdoZW4gc29tZQ0KPiBjaGFuZ2UgaGFzIHVuZXhwZWN0ZWQgY29uc2Vx dWVuY2VzLiBIZXJlIGFyZSBhIGNvdXBsZSBvZiBzaXR1YXRpb25zIHRoYXQNCj4gbWlnaHQgaGVs cCB1bmRlcnN0YW5kIHdoeSBhbiBvcGVyYXRvciBpcyBuZXJ2b3VzIGFib3V0IG5lZ290aWF0aW9u LiBUd28NCj4gcGVlcnMgKEEgYW5kIEIpIG5lZ290aWF0ZSBjcnlwdG9ncmFwaGljIGF1dGhlbnRp Y2F0aW9uLiBCZWZvcmUgYW4NCj4gdXBncmFkZSwgZXZlcnl0aGluZyBpcyB3b3JraW5nLiBCIHN1 cHBvcnRzIFNIQS0xIGFuZCBTSEEtMjU2LCBidXQgQSBvbmx5DQo+IHN1cHBvcnRzIFNIQS0xLiBB IGlzIHVwZ3JhZGVkIGFuZCBub3cgc3VwcG9ydHMgU0hBLTI1Ni4gVW5mb3J0dW5hdGVseSwNCj4g QidzIGltcGxlbWVudGF0aW9uIG9mIHRoZSByb3V0aW5nIGF1dGhlbnRpY2F0aW9uIHVzaW5nIFNI QS0yNTYgaXMNCj4gYnVnZ3kuIFRoZSB1cGdyYWRlIGNhdXNlcyB0aGluZ3MgdG8gYnJlYWsuICBQ ZXJoYXBzIHlvdSdsbCBhcmd1ZSB0aGF0J3MNCj4gbm90IHJlYWxseSBhbiB1bmludGVuZGVkIGNv bnNlcXVlbmNlOiB1cGdyYWRlcyBzb21ldGltZXMgZXhwb3NlIGJ1Z3MgaW4NCj4gdGhlIHN5c3Rl bXMgaW52b2x2ZWQgaW4gdGhlIHVwZ3JhZGUuDQo+DQo+IEhvd2V2ZXIsIG5lZ290aWF0aW9uIGNh biBtYWtlIHByb2JsZW1zIGZhciBtb3JlIGhpZGRlbi4gQ29uc2lkZXIgYQ0KPiBuZXR3b3JrIHdp dGggcm91dGVycyBBLCBCIGFuZCBDLiBCIGFuZCBDIHN1cHBvcnQgU0hBLTI1NiBhbmQgU0hBLTEs IGJ1dA0KPiBBIGN1cnJlbnRseSBvbmx5IHN1cHBvcnRzIFNIQS0xLiBTb21lIHByb3RvY29sIHdp dGggYSBncm91cCBrZXkgaXMNCj4gaW4tdXNlLiBBIGlzIHVwZ3JhZGVkOyBhcyBhIHJlc3VsdCB0 aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIEIgYW5kIEMNCj4gaGFwcGVucy4gVGhpcyBjYW4gYmUg dGhlIGNhc2UgaWYgQydzIGltcGxlbWVudGF0aW9uIG9mIFNIQS0yNTYgZG9lcyBub3QNCj4gd29y ayB3aXRoIEIuIFNvLCBldmVuIHRob3VnaCBuZWl0aGVyIG9mIHRoZSBwYXJ0aWVzIGRpcmVjdGx5 IGludm9sdmVkIGluDQo+IHRoZSBjb21tdW5pY2F0aW9uIGNoYW5nZWQgc29mdHdhcmUgb3IgY29u ZmlndXJhdGlvbiwgdGhlIHNldCBvZg0KPiBjYXBhYmlsaXRpZXMgb24gdGhlIG5ldHdvcmsgY2hh bmdlZCwgd2hpY2ggY2hhbmdlcyB3aGF0IGlzIHVzZWQuDQo+DQo+IE9uIHRoZSBvdGhlciBoYW5k LCBuZWdvdGlhdGlvbiBpbiBzZWN1cml0eSBwcm90b2NvbHMgaXMgdXNlZnVsLiBVc2Vycw0KPiBk b24ndCB0ZW5kIHRvIHVwZGF0ZSBjb25maWd1cmF0aW9ucy4gQWxzbywgdGhlIG1vcmUgeW91IGhh dmUgdG8NCj4gY29uZmlndXJlLCB0aGUgaGFyZGVyIGl0IGlzIHRvIGdldCBzZWN1cml0eSB3b3Jr aW5nLiBJZiBzZWN1cml0eQ0KPiBwYXJhbWV0ZXJzIGNhbiBiZSBkZXRlcm1pbmVkIGF1dG9tYXRp Y2FsbHkgd2l0aG91dCBjb21wcm9taXNpbmcNCj4gc2VjdXJpdHksIHVzYWJpbGl0eSBpcyBpbmNy ZWFzZWQuIE5lZ290aWF0aW9uIHdpbGwgbGVhZCB0byB0aGUgZ3JhZHVhbA0KPiBkZXBsb3ltZW50 IG9mIGJldHRlciBwcm90b2NvbHMgYXMgc29mdHdhcmUgaXMgdXBkYXRlZC4gU28sIG5lZ290aWF0 aW9uDQo+IGlzIGRlc2lyYWJsZS4NCj4NCj4gT3VyIGpvYiBpcyB0byBiYWxhbmNlIHRoZXNlIHRy YWRlb2Zmcy4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4ga2FycCBtYWlsaW5nIGxpc3QNCj4ga2FycEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2thcnANCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQprYXJwIG1haWxpbmcgbGlzdA0Ka2FycEBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9rYXJwDQoNCg0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3Jn YW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lw aWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBh cmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1l c3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBo YXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lz dGVtLg0K --=_alternative 002E5D424825781D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBNaWNoYWVsLDwvZm9udD48L3R0Pg0KPGJyPg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+SSBkbyBhZ3JlZSB3aXRoIHlvdS48L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPkNoZWVycyw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPkVsbGVuIChYaWFvcGluZyBMaWFuZyk8L2ZvbnQ+PC90dD4NCjxicj48Zm9udCBzaXpl PTEgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtNaWNoYWVsIEJhcm5lcyZxdW90Ow0KJmx0O21pY2hh ZWxfYmFybmVzQHVzYS5uZXQmZ3Q7PC9iPiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7a2FycC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDEtMTQgMDA6NDI8L2ZvbnQ+ DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7I yzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U2FtIEhh cnRtYW4gJmx0O2hhcnRtYW5zLWlldGZAbWl0LmVkdSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmth cnBAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBba2FycF0gTmVnb3RpYXRpb248L2Zv bnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwv dGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkhp IFNhbSw8YnI+DQo8YnI+DQpJIHRoaW5rIHRoZXJlIGFyZSBtYW55IHdheXMgaW4gd2hpY2ggYXV0 byBuZWdvdGlhdGlvbiBjYW4gYmVuZWZpdCB1c2Vycw0KYW5kPGJyPg0KaG9wZSB3ZSBjYW4gd29y ayB0aHJvdWdoIGNvbmNlcm5zLiBDb25maWd1cmF0aW9uIGNvbXBsZXhpdHkgaXMgb25lIHJlYXNv bg0KdGhhdDxicj4NCm9wZXJhdG9ycyBkb24ndCB1c2Ugc29waGlzdGljYXRlZCBzZWN1cml0eSwg c28gcmVkdWNpbmcgdGhlIGNvbmZpZ3VyYXRpb248YnI+DQplZmZvcnQgc2hvdWxkIGluY3JlYXNl IGRlcGxveW1lbnRzLjxicj4NCjxicj4NCkkgc3VnZ2VzdCB0aGF0IGEgbmVnb3RpYXRpb24gbWVj aGFuaXNtIGJlIGF2YWlsYWJsZSBidXQgZGVzaWduZWQgc28gdGhhdA0KYTxicj4NCnVzZXIgY2Fu IGNvbnRyb2wgaXQsIG9yIGV2ZW4gZGlzYWJsZSBpdCwgdGhyb3VnaCBjb25maWd1cmF0aW9uLiBU aGlzIHdheQ0KaWYgYTxicj4NCnVzZXIgaGFzIHNvbWUgcmVhc29uIHRvIGJlIGNvbmNlcm5lZCB0 aGF0IHRoZSBuZWdvdGlhdGlvbiBtZWNoYW5pc20gd29uJ3QNCndvcms8YnI+DQpjb3JyZWN0bHkg b3Igc29tZSBpc3N1ZXMgbWlnaHQgYmUgaW50cm9kdWNlZCBieSB1c2luZyBzdWNoIGEgbWVjaGFu aXNtLA0KZm9yPGJyPg0KZXhhbXBsZSBpZiB0aGV5IGFyZSB1c2luZyBkZXZpY2VzIGZyb20gbXVs dGlwbGUgdmVuZG9ycyBhbmQgZG9uJ3QgdHJ1c3QNCnRob3NlPGJyPg0KZGV2aWNlcyB0byBiZSBp bnRlcm9wZXJhYmxlLCB0aGVuIHRoZSBvcGVyYXRvciBjYW4gY2FyZWZ1bGx5IGNvbnRyb2wgdGhl PGJyPg0KYXV0aGVudGljYXRpb24gcGFyYW1ldGVycy48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4N Ck1pY2hhZWw8YnI+DQo8YnI+DQotLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS08YnI+DQpS ZWNlaXZlZDogVGh1LCAxMyBKYW4gMjAxMSAwODowMzozNSBBTSBQU1Q8YnI+DQpGcm9tOiBTYW0g SGFydG1hbiAmbHQ7aGFydG1hbnMtaWV0ZkBtaXQuZWR1Jmd0Ozxicj4NClRvOiBrYXJwQGlldGYu b3JnPGJyPg0KU3ViamVjdDogW2thcnBdIE5lZ290aWF0aW9uPGJyPg0KPGJyPg0KJmd0OyBBdCB0 aGUgbGFzdCBtZWV0aW5nLCBZaW54aW5nIFdlaSBhc2tlZCBhYm91dCBvdXIgc3RyYXRlZ3kgZm9y PGJyPg0KJmd0OyBuZWdvdGlhdGlvbiBvZiBjcnlwdG9ncmFwaGljIHBhcmFtZXRlcnMuPGJyPg0K Jmd0Ozxicj4NCiZndDsgSSB0aGluayB0aGlzIGlzIGFuIGltcG9ydGFudCBkaXNjdXNzaW9uIHRv IGhhdmUuICZuYnNwO0l0J3MgYW5vdGhlcg0KYXJlYTxicj4NCiZndDsgd2hlcmUgSSB0aGluayB3 ZSBtYXkgZmluZCB0aGUgc2VjdXJpdHkgYXJlYSdzIGRlZmF1bHQgYXNzdW1wdGlvbnMNCmRpZmZl cjxicj4NCiZndDsgZnJvbSB0aGUgcm91dGluZyBhcmVhLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkg ZG9uJ3QgaGF2ZSBzdHJvbmcgb3BpbmlvbnMgb24gd2hhdCB0aGUgYW5zd2VyIGlzLCBzbyBwZXJo YXBzIEkgY2FuDQp0cnk8YnI+DQomZ3Q7IGFuZCBvdXRsaW5lIGJvdGggc2lkZXMgYXMgSSB1bmRl cnN0YW5kIHRoZW0uICZuYnNwO1BlcmhhcHMgdGhpcyB3aWxsDQpoZWxwIGdldDxicj4NCiZndDsg dGhpbmdzIHN0YXJ0ZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgUm91dGluZyBwcm90b2NvbHMgaGF2 ZSBhIGZhaXIgYml0IG9mIGNvbmZpZ3VyYXRpb24uIEZvciBCR1AsIHlvdSBuZWVkDQp0bzxicj4N CiZndDsgY29uZmlndXJlIHBlZXJzLCBBUyBpbmZvcm1hdGlvbiBhbmQgYSBoZWNrIG9mIGEgbG90 IG9mIHBvbGljeS4gRXZlbg0KZm9yPGJyPg0KJmd0OyBzb21ldGhpbmcgbGlrZSBPU1BGIGFuZCBJ Uy1JUyB0aGF0IHRyeSB0byBoYXZlIGEgZmFpciBiaXQgb2YgYXV0b21hdGVkPGJyPg0KJmd0OyBk aXNjb3ZlcnksIHlvdSBuZWVkIHRvIGluZGljYXRlIHdoYXQgYXJlYSBhbiBpbnRlcmZhY2UgaXMg aW4uIFRoaXM8YnI+DQomZ3Q7IGNvbmZpZ3VyYXRpb24gbmVlZHMgdG8gYmUgY29uc2lzdGVudCBh bmQgc3luY2hyb25pemVkLiBBcyBhIHJlc3VsdCw8YnI+DQomZ3Q7IGFueW9uZSB3aG8gaGFzIG1v cmUgdGhhbiBhIGNvdXBsZSBvZiByb3V0ZXJzIGhhcyBtZWNoYW5pc21zIGZvciBtYW5hZ2luZzxi cj4NCiZndDsgYW5kIHVwZGF0aW5nIGNvbmZpZ3VyYXRpb24uIFVwZGF0aW5nIHdoYXQgY3J5cHRv Z3JhcGhpYyBhbGdvcml0aG1zDQp0bzxicj4NCiZndDsgdXNlIGluIGEgY29uZmlndXJhdGlvbiBp cyBub3QgdGhhdCBkaWZmaWN1bHQuPGJyPg0KJmd0Ozxicj4NCiZndDsgT25lIGhpZ2hseSB1bmRl c2lyYWJsZSB0aGluZyBpbiBhbiBvcGVyYXRpb25hbCBuZXR3b3JrIGlzIHdoZW4gc29tZTxicj4N CiZndDsgY2hhbmdlIGhhcyB1bmV4cGVjdGVkIGNvbnNlcXVlbmNlcy4gSGVyZSBhcmUgYSBjb3Vw bGUgb2Ygc2l0dWF0aW9ucw0KdGhhdDxicj4NCiZndDsgbWlnaHQgaGVscCB1bmRlcnN0YW5kIHdo eSBhbiBvcGVyYXRvciBpcyBuZXJ2b3VzIGFib3V0IG5lZ290aWF0aW9uLg0KVHdvPGJyPg0KJmd0 OyBwZWVycyAoQSBhbmQgQikgbmVnb3RpYXRlIGNyeXB0b2dyYXBoaWMgYXV0aGVudGljYXRpb24u IEJlZm9yZSBhbjxicj4NCiZndDsgdXBncmFkZSwgZXZlcnl0aGluZyBpcyB3b3JraW5nLiBCIHN1 cHBvcnRzIFNIQS0xIGFuZCBTSEEtMjU2LCBidXQNCkEgb25seTxicj4NCiZndDsgc3VwcG9ydHMg U0hBLTEuIEEgaXMgdXBncmFkZWQgYW5kIG5vdyBzdXBwb3J0cyBTSEEtMjU2LiBVbmZvcnR1bmF0 ZWx5LDxicj4NCiZndDsgQidzIGltcGxlbWVudGF0aW9uIG9mIHRoZSByb3V0aW5nIGF1dGhlbnRp Y2F0aW9uIHVzaW5nIFNIQS0yNTYgaXM8YnI+DQomZ3Q7IGJ1Z2d5LiBUaGUgdXBncmFkZSBjYXVz ZXMgdGhpbmdzIHRvIGJyZWFrLiAmbmJzcDtQZXJoYXBzIHlvdSdsbCBhcmd1ZQ0KdGhhdCdzPGJy Pg0KJmd0OyBub3QgcmVhbGx5IGFuIHVuaW50ZW5kZWQgY29uc2VxdWVuY2U6IHVwZ3JhZGVzIHNv bWV0aW1lcyBleHBvc2UgYnVncw0KaW48YnI+DQomZ3Q7IHRoZSBzeXN0ZW1zIGludm9sdmVkIGlu IHRoZSB1cGdyYWRlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEhvd2V2ZXIsIG5lZ290aWF0aW9uIGNh biBtYWtlIHByb2JsZW1zIGZhciBtb3JlIGhpZGRlbi4gQ29uc2lkZXIgYTxicj4NCiZndDsgbmV0 d29yayB3aXRoIHJvdXRlcnMgQSwgQiBhbmQgQy4gQiBhbmQgQyBzdXBwb3J0IFNIQS0yNTYgYW5k IFNIQS0xLA0KYnV0PGJyPg0KJmd0OyBBIGN1cnJlbnRseSBvbmx5IHN1cHBvcnRzIFNIQS0xLiBT b21lIHByb3RvY29sIHdpdGggYSBncm91cCBrZXkgaXM8YnI+DQomZ3Q7IGluLXVzZS4gQSBpcyB1 cGdyYWRlZDsgYXMgYSByZXN1bHQgdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBCIGFuZA0KQzxi cj4NCiZndDsgaGFwcGVucy4gVGhpcyBjYW4gYmUgdGhlIGNhc2UgaWYgQydzIGltcGxlbWVudGF0 aW9uIG9mIFNIQS0yNTYgZG9lcw0Kbm90PGJyPg0KJmd0OyB3b3JrIHdpdGggQi4gU28sIGV2ZW4g dGhvdWdoIG5laXRoZXIgb2YgdGhlIHBhcnRpZXMgZGlyZWN0bHkgaW52b2x2ZWQNCmluPGJyPg0K Jmd0OyB0aGUgY29tbXVuaWNhdGlvbiBjaGFuZ2VkIHNvZnR3YXJlIG9yIGNvbmZpZ3VyYXRpb24s IHRoZSBzZXQgb2Y8YnI+DQomZ3Q7IGNhcGFiaWxpdGllcyBvbiB0aGUgbmV0d29yayBjaGFuZ2Vk LCB3aGljaCBjaGFuZ2VzIHdoYXQgaXMgdXNlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiB0aGUg b3RoZXIgaGFuZCwgbmVnb3RpYXRpb24gaW4gc2VjdXJpdHkgcHJvdG9jb2xzIGlzIHVzZWZ1bC4g VXNlcnM8YnI+DQomZ3Q7IGRvbid0IHRlbmQgdG8gdXBkYXRlIGNvbmZpZ3VyYXRpb25zLiBBbHNv LCB0aGUgbW9yZSB5b3UgaGF2ZSB0bzxicj4NCiZndDsgY29uZmlndXJlLCB0aGUgaGFyZGVyIGl0 IGlzIHRvIGdldCBzZWN1cml0eSB3b3JraW5nLiBJZiBzZWN1cml0eTxicj4NCiZndDsgcGFyYW1l dGVycyBjYW4gYmUgZGV0ZXJtaW5lZCBhdXRvbWF0aWNhbGx5IHdpdGhvdXQgY29tcHJvbWlzaW5n PGJyPg0KJmd0OyBzZWN1cml0eSwgdXNhYmlsaXR5IGlzIGluY3JlYXNlZC4gTmVnb3RpYXRpb24g d2lsbCBsZWFkIHRvIHRoZSBncmFkdWFsPGJyPg0KJmd0OyBkZXBsb3ltZW50IG9mIGJldHRlciBw cm90b2NvbHMgYXMgc29mdHdhcmUgaXMgdXBkYXRlZC4gU28sIG5lZ290aWF0aW9uPGJyPg0KJmd0 OyBpcyBkZXNpcmFibGUuPGJyPg0KJmd0Ozxicj4NCiZndDsgT3VyIGpvYiBpcyB0byBiYWxhbmNl IHRoZXNlIHRyYWRlb2Zmcy48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBrYXJwIG1haWxpbmcgbGlzdDxicj4NCiZndDsg a2FycEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9rYXJwPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQprYXJwIG1haWxpbmcgbGlzdDxicj4NCmthcnBA aWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2thcnA8 YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9y bWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRp b24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJz cDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJz cDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5i c3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7 YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7 c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3Rv Jm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZu YnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZu YnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5i c3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZu YnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7 dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUm bmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJz cDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJz cDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5i c3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2Um bmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJz cDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0 ZW0uDQo8L3ByZT4= --=_alternative 002E5D424825781D_=-- From liang.xiaoping@zte.com.cn Wed Jan 19 00:39:22 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 BE8853A6EB1; Wed, 19 Jan 2011 00:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.554 X-Spam-Level: X-Spam-Status: No, score=-94.554 tagged_above=-999 required=5 tests=[AWL=-1.765, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 DNYH5L2E1oHY; Wed, 19 Jan 2011 00:39:21 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id D44C73A6E80; Wed, 19 Jan 2011 00:39:20 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35102175658078; Wed, 19 Jan 2011 16:40:01 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 96520.5162356210; Wed, 19 Jan 2011 16:41:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p0J8feD1099669; Wed, 19 Jan 2011 16:41:40 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: To: Sam Hartman MIME-Version: 1.0 X-KeepSent: 55ED50C6:9F82937E-4825781D:002E6541; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Wed, 19 Jan 2011 16:41:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-19 16:41:43, Serialize complete at 2011-01-19 16:41:43 Content-Type: multipart/alternative; boundary="=_alternative 002FC1DD4825781D_=" X-MAIL: mse02.zte.com.cn p0J8feD1099669 Cc: karp-bounces@ietf.org, karp@ietf.org Subject: [karp] =?gb2312?b?tPC4tDogUmU6ICBOZWdvdGlhdGlvbg==?= 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, 19 Jan 2011 08:39:22 -0000 This is a multipart message in MIME format. --=_alternative 002FC1DD4825781D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2FtLA0KDQpJbiBteSBwZXJzb25hbCBvcGluaW9uLCB0aGUgYXBwcm9hY2ggeW91IHByb3Bv c2VkIGlzIHZlcnkgc3VpdGFibGUgZm9yIA0KbWFudWFsIGtleWluZyBjYXNlLCBhbmQgaWYgd2Ug Y29uc2lkZXIgYXV0b21hdGVkIEtNUCBhbmQgYmV0dGVyIHNlY3VyaXR5LCANCm5lZ290aWF0aW9u IGlzIGEgTVVTVCwgYW5kIGNhbmNlbGxpbmcgbmVnb3RpYXRpb24gY291bGQgYmUgYW4gb3B0aW9u LiANCg0KV2hhdCBpcyB5b3VyIGNvbmNlcm5zLCBHcmVnb3J5IGFuZCBvdGhlciBwZW9wbGU/DQoN CkNoZWVycywNCkVsbGVuIChYaWFvcGluZyBMaWFuZykNCiANCg0KDQoNClNhbSBIYXJ0bWFuIDxo YXJ0bWFucy1pZXRmQG1pdC5lZHU+IA0Kt6K8/sjLOiAga2FycC1ib3VuY2VzQGlldGYub3JnDQoy MDExLTAxLTE0IDAxOjAyDQoNCsrVvP7Iyw0KIk1pY2hhZWwgQmFybmVzIiA8bWljaGFlbF9iYXJu ZXNAdXNhLm5ldD4NCrOty80NClNhbSBIYXJ0bWFuIDxoYXJ0bWFucy1pZXRmQG1pdC5lZHU+LCBr YXJwQGlldGYub3JnDQrW98ziDQpSZTogW2thcnBdIE5lZ290aWF0aW9uDQoNCg0KDQoNCg0KDQo+ Pj4+PiAiTWljaGFlbCIgPT0gTWljaGFlbCBCYXJuZXMgPG1pY2hhZWxfYmFybmVzQHVzYS5uZXQ+ IHdyaXRlczoNCg0KICAgIE1pY2hhZWw+IEkgc3VnZ2VzdCB0aGF0IGEgbmVnb3RpYXRpb24gbWVj aGFuaXNtIGJlIGF2YWlsYWJsZSBidXQNCiAgICBNaWNoYWVsPiBkZXNpZ25lZCBzbyB0aGF0IGEg dXNlciBjYW4gY29udHJvbCBpdCwgb3IgZXZlbiBkaXNhYmxlIGl0LA0KICAgIE1pY2hhZWw+IHRo cm91Z2ggY29uZmlndXJhdGlvbi4gVGhpcyB3YXkgaWYgYSB1c2VyIGhhcyBzb21lIHJlYXNvbg0K ICAgIE1pY2hhZWw+IHRvIGJlIGNvbmNlcm5lZCB0aGF0IHRoZSBuZWdvdGlhdGlvbiBtZWNoYW5p c20gd29uJ3Qgd29yaw0KICAgIE1pY2hhZWw+IGNvcnJlY3RseSBvciBzb21lIGlzc3VlcyBtaWdo dCBiZSBpbnRyb2R1Y2VkIGJ5IHVzaW5nIHN1Y2gNCiAgICBNaWNoYWVsPiBhIG1lY2hhbmlzbSwg Zm9yIGV4YW1wbGUgaWYgdGhleSBhcmUgdXNpbmcgZGV2aWNlcyBmcm9tDQogICAgTWljaGFlbD4g bXVsdGlwbGUgdmVuZG9ycyBhbmQgZG9uJ3QgdHJ1c3QgdGhvc2UgZGV2aWNlcyB0byBiZQ0KICAg IE1pY2hhZWw+IGludGVyb3BlcmFibGUsIHRoZW4gdGhlIG9wZXJhdG9yIGNhbiBjYXJlZnVsbHkg Y29udHJvbCB0aGUNCiAgICBNaWNoYWVsPiBhdXRoZW50aWNhdGlvbiBwYXJhbWV0ZXJzLg0KDQoN CkkgdGhpbmsgdGhhdCB0aGUgYmVzdCB3YXkgdG8gZG8gdGhpcyBpZiBkZXNpcmVkIHRvIHNpbXBs eSBwZXJtaXQgYSB1c2VyDQp0byBjb25zdHJhaW4gdGhlIHNldCBvZiBhbGxvd2VkIG5lZ290aWF0 aW9uIHJlc3VsdHMgZG93biB0byBvbmUgb3B0aW9uLg0KVGhhdCByZW1vdmVzIHRoZSB0ZXN0aW5n IGNvbXBsZXhpdHkgb2Ygc29tZXRpbWVzIGhhdmluZyBuZWdvdGlhdGlvbiBhbmQNCnNvbWV0aW1l cyBub3QuDQoNCklmIHdlIGNhbiBnZXQgY29uc2Vuc3VzIGJlaGluZCB0aGlzIEknbSBmaW5lLiAg SSBrbm93IHRoYXQgR3JlZ29yeSBhbmQgYQ0KY291cGxlIG9mIG90aGVycyBoYXZlIGV4cHJlc3Nl ZCBjb25jZXJucyBhYm91dCB0aGlzIGFwcHJvYWNoLg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmthcnAgbWFpbGluZyBsaXN0DQprYXJwQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2thcnANCg0KDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6 YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50 cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBu b3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRp b24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGgg aXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmln aW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2Fn ZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBi ZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0u DQo= --=_alternative 002FC1DD4825781D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBTYW0sPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5JbiBteSBwZXJzb25hbCBvcGluaW9uLCB0aGUgYXBwcm9hY2ggeW91IHBy b3Bvc2VkDQppcyB2ZXJ5IHN1aXRhYmxlIGZvciBtYW51YWwga2V5aW5nIGNhc2UsIGFuZCBpZiB3 ZSBjb25zaWRlciBhdXRvbWF0ZWQgS01QDQphbmQgYmV0dGVyIHNlY3VyaXR5LCBuZWdvdGlhdGlv biBpcyBhIE1VU1QsIGFuZCBjYW5jZWxsaW5nIG5lZ290aWF0aW9uDQpjb3VsZCBiZSBhbiBvcHRp b24uICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5XaGF0IGlzIHlvdXIgY29uY2VybnMsIEdyZWdvcnkgYW5kIG90aGVyIHBlb3BsZT88 L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkNoZWVycyw8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkVsbGVuIChYaWFvcGluZyBMaWFuZyk8L2ZvbnQ+PC90 dD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj4NCjxi cj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5TYW0gSGFydG1hbiAmbHQ7aGFy dG1hbnMtaWV0ZkBtaXQuZWR1Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtrYXJwLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMS0wMS0xNCAwMTowMjwvZm9u dD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8 /sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVv dDtNaWNoYWVsIEJhcm5lcyZxdW90OyAmbHQ7bWljaGFlbF9iYXJuZXNAdXNhLm5ldCZndDs8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPlNhbSBIYXJ0bWFuICZsdDtoYXJ0bWFucy1pZXRmQG1pdC5lZHUmZ3Q7 LA0Ka2FycEBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtrYXJwXSBOZWdvdGlhdGlv bjwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7TWljaGFlbCZxdW90OyA9PSBNaWNoYWVsDQpC YXJuZXMgJmx0O21pY2hhZWxfYmFybmVzQHVzYS5uZXQmZ3Q7IHdyaXRlczo8YnI+DQo8YnI+DQog Jm5ic3A7ICZuYnNwO01pY2hhZWwmZ3Q7IEkgc3VnZ2VzdCB0aGF0IGEgbmVnb3RpYXRpb24gbWVj aGFuaXNtIGJlIGF2YWlsYWJsZQ0KYnV0PGJyPg0KICZuYnNwOyAmbmJzcDtNaWNoYWVsJmd0OyBk ZXNpZ25lZCBzbyB0aGF0IGEgdXNlciBjYW4gY29udHJvbCBpdCwgb3IgZXZlbg0KZGlzYWJsZSBp dCw8YnI+DQogJm5ic3A7ICZuYnNwO01pY2hhZWwmZ3Q7IHRocm91Z2ggY29uZmlndXJhdGlvbi4g VGhpcyB3YXkgaWYgYSB1c2VyIGhhcw0Kc29tZSByZWFzb248YnI+DQogJm5ic3A7ICZuYnNwO01p Y2hhZWwmZ3Q7IHRvIGJlIGNvbmNlcm5lZCB0aGF0IHRoZSBuZWdvdGlhdGlvbiBtZWNoYW5pc20N Cndvbid0IHdvcms8YnI+DQogJm5ic3A7ICZuYnNwO01pY2hhZWwmZ3Q7IGNvcnJlY3RseSBvciBz b21lIGlzc3VlcyBtaWdodCBiZSBpbnRyb2R1Y2VkDQpieSB1c2luZyBzdWNoPGJyPg0KICZuYnNw OyAmbmJzcDtNaWNoYWVsJmd0OyBhIG1lY2hhbmlzbSwgZm9yIGV4YW1wbGUgaWYgdGhleSBhcmUg dXNpbmcgZGV2aWNlcw0KZnJvbTxicj4NCiAmbmJzcDsgJm5ic3A7TWljaGFlbCZndDsgbXVsdGlw bGUgdmVuZG9ycyBhbmQgZG9uJ3QgdHJ1c3QgdGhvc2UgZGV2aWNlcw0KdG8gYmU8YnI+DQogJm5i c3A7ICZuYnNwO01pY2hhZWwmZ3Q7IGludGVyb3BlcmFibGUsIHRoZW4gdGhlIG9wZXJhdG9yIGNh biBjYXJlZnVsbHkNCmNvbnRyb2wgdGhlPGJyPg0KICZuYnNwOyAmbmJzcDtNaWNoYWVsJmd0OyBh dXRoZW50aWNhdGlvbiBwYXJhbWV0ZXJzLjxicj4NCjxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCB0 aGUgYmVzdCB3YXkgdG8gZG8gdGhpcyBpZiBkZXNpcmVkIHRvIHNpbXBseSBwZXJtaXQgYSB1c2Vy PGJyPg0KdG8gY29uc3RyYWluIHRoZSBzZXQgb2YgYWxsb3dlZCBuZWdvdGlhdGlvbiByZXN1bHRz IGRvd24gdG8gb25lIG9wdGlvbi48YnI+DQpUaGF0IHJlbW92ZXMgdGhlIHRlc3RpbmcgY29tcGxl eGl0eSBvZiBzb21ldGltZXMgaGF2aW5nIG5lZ290aWF0aW9uIGFuZDxicj4NCnNvbWV0aW1lcyBu b3QuPGJyPg0KPGJyPg0KSWYgd2UgY2FuIGdldCBjb25zZW5zdXMgYmVoaW5kIHRoaXMgSSdtIGZp bmUuICZuYnNwO0kga25vdyB0aGF0IEdyZWdvcnkNCmFuZCBhPGJyPg0KY291cGxlIG9mIG90aGVy cyBoYXZlIGV4cHJlc3NlZCBjb25jZXJucyBhYm91dCB0aGlzIGFwcHJvYWNoLjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Ka2FycCBtYWls aW5nIGxpc3Q8YnI+DQprYXJwQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9rYXJwPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHBy ZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNw O1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5i c3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5i c3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVu dHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8m bmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJz cDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMm bmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMu DQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5z bWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7 YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2Um bmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNw O3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYm bmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJz cDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3Jp Z2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3 cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUm bmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4N ClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtm b3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7 QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 002FC1DD4825781D_=-- From hartmans@mit.edu Wed Jan 19 06:02: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 67E313A712B; Wed, 19 Jan 2011 06:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.127 X-Spam-Level: X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=-1.351, BAYES_05=-1.11, 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 a+Z4nvcxNp64; Wed, 19 Jan 2011 06:02:48 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B45543A7120; Wed, 19 Jan 2011 06:02:48 -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 7A26F20222; Wed, 19 Jan 2011 09:03:44 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C3B08432C; Wed, 19 Jan 2011 09:05:23 -0500 (EST) From: Sam Hartman To: liang.xiaoping@zte.com.cn References: Date: Wed, 19 Jan 2011 09:05:23 -0500 In-Reply-To: (liang xiaoping's message of "Wed, 19 Jan 2011 16:22:31 +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-bounces@ietf.org, Sam Hartman , karp@ietf.org Subject: Re: [karp] Negotiation 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, 19 Jan 2011 14:02:49 -0000 >>>>> "liang" == liang xiaoping writes: liang> What you pointed out in the email is very importment, and liang> negotiation directly for routers in current use without more liang> work will DO introduce risks, and even bring out severe liang> consequences. But without negotiation, it is very difficule liang> to achieve better security and better liang> interoperation/interconnection. One thing we should do is write up the clear advantages of negotiation. I think the main advantage is that it permits deployment of new cryptographic algorithms via the gradual process of upgrading software and equipment without the explicit action of operators to do so. Are there other significant advantages in the KARP context? From mjbarnes@cisco.com Wed Jan 19 09:33:06 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 A009428C0D8; Wed, 19 Jan 2011 09:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXBfU15DBlBt; Wed, 19 Jan 2011 09:33:05 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id EA29D3A7187; Wed, 19 Jan 2011 09:33:05 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAuwNk2rR7H+/2dsb2JhbACkR3OkbZoThVAEhG+GL4MkiBY Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2011 17:35:46 +0000 Received: from [10.33.12.118] ([10.33.12.118]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0JHZkDm003536; Wed, 19 Jan 2011 17:35:46 GMT Message-ID: <4D3720F2.70301@cisco.com> Date: Wed, 19 Jan 2011 09:35:46 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Sam Hartman References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DF0F7@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D3029F7.6040107@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" , "karp@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: Wed, 19 Jan 2011 17:33:06 -0000 Hi Sam, On 01/14/2011 04:34 AM, Sam Hartman wrote: > We could have separate authentication challenge packets. However, the > advantage of the current approach is that I think we can get to a point > where we have one or two extra packets total for a cold-start situation, > rather than an extra packet or two per neighbor. I don't know that the > current rules for receiving and sending packets actually achieve this, > but I believe we can get there with some minor changes. I've been giving this some thought, and I think exchanging a couple of additional packets in the cold start situation is more desirable than overloading the Hello packet with an additional security role. The Hello packet already services two very important purposes - discovery and keep alive. It is highly desirable not to add to the processing overhead for these packets. Have you and the other authors already given thought to a design using a new packet type for challenge/response packets? Thanks, Michael From hartmans@mit.edu Wed Jan 19 10:10: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 D56F028C0EB; Wed, 19 Jan 2011 10:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.829 X-Spam-Level: X-Spam-Status: No, score=-102.829 tagged_above=-999 required=5 tests=[AWL=-0.564, 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 FRZwpUN8OBLR; Wed, 19 Jan 2011 10:10:53 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id AC12B28C12D; Wed, 19 Jan 2011 10:10:52 -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 A31F420239; Wed, 19 Jan 2011 13:11:48 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7F1F5432C; Wed, 19 Jan 2011 13:13:24 -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> Date: Wed, 19 Jan 2011 13:13:24 -0500 In-Reply-To: <4D3720F2.70301@cisco.com> (Michael Barnes's message of "Wed, 19 Jan 2011 09:35:46 -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: "ospf@ietf.org" , "karp@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: Wed, 19 Jan 2011 18:10:54 -0000 >>>>> "Michael" == Michael Barnes writes: Michael> Hi Sam, Michael> On 01/14/2011 04:34 AM, Sam Hartman wrote: >> We could have separate authentication challenge packets. >> However, the advantage of the current approach is that I think we >> can get to a point where we have one or two extra packets total >> for a cold-start situation, rather than an extra packet or two >> per neighbor. I don't know that the current rules for receiving >> and sending packets actually achieve this, but I believe we can >> get there with some minor changes. Michael> I've been giving this some thought, and I think exchanging Michael> a couple of additional packets in the cold start situation Michael> is more desirable than overloading the Hello packet with an Michael> additional security role. The Hello packet already services Michael> two very important purposes - discovery and keep alive. It Michael> is highly desirable not to add to the processing overhead Michael> for these packets. I'd like to understand your concerns here. Are you concerned about CPU for processing the hello packet? Bandwidth of the hello packets? I'd like to actually get educated about the tradeoffs enough that I can have an intelligent discussion. --Sam From mjbarnes@cisco.com Wed Jan 19 10:35:09 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 393A73A6FEC; Wed, 19 Jan 2011 10:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFS5A7SGedbH; Wed, 19 Jan 2011 10:35:07 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AF2AF28C0F4; Wed, 19 Jan 2011 10:35:07 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABu+Nk2rR7H+/2dsb2JhbACkR3OkXpo8hVAEhG+GL4MkiBY Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2011 18:37:47 +0000 Received: from [128.107.114.137] (dhcp-128-107-114-137.cisco.com [128.107.114.137]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0JIbl5Y005025; Wed, 19 Jan 2011 18:37:47 GMT Message-ID: <4D372F7B.9030507@cisco.com> Date: Wed, 19 Jan 2011 10:37:47 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Sam Hartman 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ospf@ietf.org" , "karp@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: Wed, 19 Jan 2011 18:35:09 -0000 Hi Sam, On 01/19/2011 10:13 AM, Sam Hartman wrote: >>>>>> "Michael" == Michael Barnes writes: > > Michael> Hi Sam, > Michael> On 01/14/2011 04:34 AM, Sam Hartman wrote: > >> We could have separate authentication challenge packets. > >> However, the advantage of the current approach is that I think we > >> can get to a point where we have one or two extra packets total > >> for a cold-start situation, rather than an extra packet or two > >> per neighbor. I don't know that the current rules for receiving > >> and sending packets actually achieve this, but I believe we can > >> get there with some minor changes. > > Michael> I've been giving this some thought, and I think exchanging > Michael> a couple of additional packets in the cold start situation > Michael> is more desirable than overloading the Hello packet with an > Michael> additional security role. The Hello packet already services > Michael> two very important purposes - discovery and keep alive. It > Michael> is highly desirable not to add to the processing overhead > Michael> for these packets. > > I'd like to understand your concerns here. Are you concerned about CPU > for processing the hello packet? Bandwidth of the hello packets? I'd > like to actually get educated about the tradeoffs enough that I can have > an intelligent discussion. I don't think the bandwidth is really an issue, but CPU is. It is important that processing of these packets can be completed as quickly as possible. We are constantly being asked to scale to ever larger number of neighbors and adding overhead to Hello packets could make this security mechanism undesirable in those settings. Regards, Michael From glen.kent@gmail.com Wed Jan 19 16:26: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 9A07C28C117; Wed, 19 Jan 2011 16:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.076 X-Spam-Level: X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=0.523, 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 I74Yx5HcDkdI; Wed, 19 Jan 2011 16:26:14 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 2E8AE28C0E4; Wed, 19 Jan 2011 16:26:13 -0800 (PST) Received: by eyd10 with SMTP id 10so9138eyd.31 for ; Wed, 19 Jan 2011 16:28:53 -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=/GfqkLErq1/25P0mlIpY3yto+UP+8Sw4uFDDnkroess=; b=JyNgYsLm5FYmKVG96a2aTPQiZSTNeKBMt5kqbi1emp3wp35RMXvNHciaRguoq7TjMs fUa4Vg8x5ceSFADeidZesdZrcIYcGgQBVR+jSt7z1AY4tE/7296C9W4iYaV6Z9eTeHoW dAG4+usr5LSl7cK8//GgXk/C/5Gdt34RG46HE= 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=ksgBUxAMDHKEyD9mqqc0LWgOWNyMhF/SauUFQbxhTbtwXaQD3LPyt0MHlGSYHTkcWe IQFisG9GGL50qqdNdA48Br5+fVpK5fD90EvGe9eKVgP92a6pTIeXRqRMAgmGC6MhkwzG kUbMaUD4OZNfsajKW4I9bdkGKUCSWRVhgxCCA= MIME-Version: 1.0 Received: by 10.14.119.1 with SMTP id m1mr1719828eeh.28.1295483333742; Wed, 19 Jan 2011 16:28:53 -0800 (PST) Received: by 10.14.125.146 with HTTP; Wed, 19 Jan 2011 16:28:53 -0800 (PST) In-Reply-To: <4D372F7B.9030507@cisco.com> 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> Date: Thu, 20 Jan 2011 05:58:53 +0530 Message-ID: From: Glen Kent To: Michael Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ospf@ietf.org" , Sam Hartman , "karp@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: Thu, 20 Jan 2011 00:26:15 -0000 Can i request the authors to post a revised ID fixing the Authentication details in the OSPF header. At present, i am confused as i dont see the Key ID, Sequence Numbers anywhere in the packets. I agree that some discussion on overloading of the Hellos must happen. However, i would also like to see some discussion on whether the proposed mechanism of Nonces and Session IDs would work. I think that is the key element in this work. If that is verified then everything else can be built around that. Glen On Thu, Jan 20, 2011 at 12:07 AM, Michael Barnes wrote= : > Hi Sam, > > On 01/19/2011 10:13 AM, Sam Hartman wrote: >>>>>>> >>>>>>> "Michael" =3D=3D Michael Barnes =A0writes: >> >> =A0 =A0 Michael> =A0Hi Sam, >> =A0 =A0 Michael> =A0On 01/14/2011 04:34 AM, Sam Hartman wrote: >> =A0 =A0 >> =A0We could have separate authentication challenge packets. >> =A0 =A0 >> =A0However, the advantage of the current approach is that I t= hink we >> =A0 =A0 >> =A0can get to a point where we have one or two extra packets = total >> =A0 =A0 >> =A0for a cold-start situation, rather than an extra packet or= two >> =A0 =A0 >> =A0per neighbor. =A0I don't know that the current rules for r= eceiving >> =A0 =A0 >> =A0and sending packets actually achieve this, but I believe w= e can >> =A0 =A0 >> =A0get there with some minor changes. >> >> =A0 =A0 Michael> =A0I've been giving this some thought, and I think exch= anging >> =A0 =A0 Michael> =A0a couple of additional packets in the cold start sit= uation >> =A0 =A0 Michael> =A0is more desirable than overloading the Hello packet = with an >> =A0 =A0 Michael> =A0additional security role. The Hello packet already s= ervices >> =A0 =A0 Michael> =A0two very important purposes - discovery and keep ali= ve. It >> =A0 =A0 Michael> =A0is highly desirable not to add to the processing ove= rhead >> =A0 =A0 Michael> =A0for these packets. >> >> I'd like to understand your concerns here. =A0Are you concerned about CP= U >> for processing the hello packet? Bandwidth of the hello packets? =A0I'd >> like to actually get educated about the tradeoffs enough that I can have >> an intelligent discussion. > > I don't think the bandwidth is really an issue, but CPU is. It is importa= nt > that processing of these packets can be completed as quickly as possible.= We > are constantly being asked to scale to ever larger number of neighbors an= d > adding overhead to Hello packets could make this security mechanism > undesirable in those settings. > > Regards, > Michael > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From manav.bhatia@alcatel-lucent.com Wed Jan 19 17:19: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 279ED28C139; Wed, 19 Jan 2011 17:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.413, 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 V15piN-ca4iC; Wed, 19 Jan 2011 17:19:49 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 1690E28C126; Wed, 19 Jan 2011 17:19:48 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0K1M0Fk026216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jan 2011 19:22:02 -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 p0K1LxKQ028017 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Jan 2011 06:51:59 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 20 Jan 2011 06:51:59 +0530 From: "Bhatia, Manav (Manav)" To: Glen Kent , Michael Barnes Date: Thu, 20 Jan 2011 06:51:57 +0530 Thread-Topic: [karp] Security Extension for OSPFv2 when using Manual Key Management Thread-Index: Acu4OQszNA9gF4OxSOaNJvfOxOphqQABxRVQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFB0DFAD4@INBANSXCHMBSA1.in.alcatel-lucent.com> 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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ospf@ietf.org" , Sam Hartman , "karp@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: Thu, 20 Jan 2011 01:19:50 -0000 Hi Glen, =20 > Can i request the authors to post a revised ID fixing the > Authentication details in the OSPF header. At present, i am confused > as i dont see the Key ID, Sequence Numbers anywhere in the packets. The revised draft has been updated and posted. Its available here: http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protection-02.txt >=20 > I agree that some discussion on overloading of the Hellos must happen. > However, i would also like to see some discussion on whether the > proposed mechanism of Nonces and Session IDs would work. I think that > is the key element in this work. If that is verified then everything > else can be built around that. Yup, I agree! Cheers, Manav >=20 > Glen From liang.xiaoping@zte.com.cn Thu Jan 20 23:43: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 18AFB3A68E1; Thu, 20 Jan 2011 23:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.795 X-Spam-Level: X-Spam-Status: No, score=-98.795 tagged_above=-999 required=5 tests=[AWL=3.043, 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 jmhv4-jYfPBk; Thu, 20 Jan 2011 23:43:10 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 314493A68D9; Thu, 20 Jan 2011 23:43:10 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205952175658078; Fri, 21 Jan 2011 15:41:14 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 15390.3208842533; Fri, 21 Jan 2011 15:38:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p0L7jcGq039384; Fri, 21 Jan 2011 15:45:38 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: To: Sam Hartman MIME-Version: 1.0 X-KeepSent: 5A3B1495:A6D3B87B-4825781F:00262B1C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Fri, 21 Jan 2011 15:45:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-21 15:45:40, Serialize complete at 2011-01-21 15:45:40 Content-Type: multipart/alternative; boundary="=_alternative 002AA18D4825781F_=" X-MAIL: mse02.zte.com.cn p0L7jcGq039384 Cc: karp-bounces@ietf.org, Sam Hartman , karp@ietf.org Subject: Re: [karp] Negotiation 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, 21 Jan 2011 07:43:12 -0000 This is a multipart message in MIME format. --=_alternative 002AA18D4825781F_= Content-Type: text/plain; charset="US-ASCII" >>>>> "liang" == liang xiaoping writes: liang> What you pointed out in the email is very importment, and liang> negotiation directly for routers in current use without more liang> work will DO introduce risks, and even bring out severe liang> consequences. But without negotiation, it is very difficule liang> to achieve better security and better liang> interoperation/interconnection. > One thing we should do is write up the clear advantages of negotiation. Hi Sam, Yes, I do agree. First, we could figure out why we need or don't need negotiation. If the answer is yes, then we could figure out what to negotiate, and how to negotiate. > I think the main advantage is that it permits deployment of new > cryptographic algorithms via the gradual process of upgrading software > and equipment without the explicit action of operators to do so. Yes, that's one strong advantage that supports negotiation. > Are there other significant advantages in the KARP context? Yes. In section 1.1 of the document threats-reqs-01, it says that "A KMP is helpful because it negotiates unique, pair wise, random keys without administrator involvement. It also negotiates as mentioned earlier several of the SA parameters required for the secure connection, including key life times. It keeps track of those lifetimes using counters, and negotiates new keys and parameters before they expire, again, without administrator interaction. Additionally, in the event of a breach, changing the KMP key will immediately cause a rekey to occur for the Traffic Key, and those new Traffic Keys will be installed and used in the current connection." And I can see from the above paragraph that the advantages of negotiation include: 1. It makes KMP provide unique session keys for routing protocols without administrator involvement. Session key is called traffic key in the document threats-reqs-01. 2. It makes KMP have flexibility to manage SA, including key lifetime and other parameters of SA. 3. It makes KMP have the ability to recover routing systems immediately in the case of security breach, and that seems very good. Other findings or opinions about the advantages of negotiation in KMP from other people? Cheers, 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 002AA18D4825781F_= Content-Type: text/html; charset="US-ASCII"


>>>>> "liang" == liang xiaoping <liang.xiaoping@zte.com.cn> writes:

   liang> What you pointed out in the email is very importment, and
   liang> negotiation directly for routers in current use without more
   liang> work will DO introduce risks, and even bring out severe
   liang> consequences. But without negotiation, it is very difficule
   liang> to achieve better security and better
   liang> interoperation/interconnection.

> One thing we should do is write up the clear advantages of negotiation.
Hi Sam,

Yes, I do agree. First, we could figure out why we need or don't need negotiation. If the answer is yes, then we could figure out what to negotiate, and how to negotiate.

> I think the main advantage is that it permits deployment of new
> cryptographic algorithms via the gradual process of upgrading software
> and equipment without the explicit action of operators to do so.
Yes, that's one strong advantage that supports negotiation.  

> Are there other significant advantages in the KARP context?
Yes. In section 1.1 of the document threats-reqs-01, it says that
 "A KMP is helpful because it negotiates unique, pair wise, random keys without administrator involvement.  It also negotiates as mentioned earlier several of the SA parameters required for the secure connection, including key life times.  It keeps track of those lifetimes using counters, and negotiates new keys and parameters before they expire, again, without administrator interaction.  Additionally, in the event of a breach, changing the KMP key will immediately cause a rekey to occur for the Traffic Key, and those new Traffic Keys will be installed and used in the current connection."

And I can see from the above paragraph that the advantages of negotiation include:
1. It makes KMP provide unique session keys for routing protocols without administrator involvement. Session key is called traffic key in the document threats-reqs-01.
2. It makes KMP have flexibility to manage SA, including key lifetime and other parameters of SA.        
3. It makes KMP have the ability to recover routing systems immediately in the case of security breach, and that seems very good.

Other findings or opinions about the advantages of negotiation in KMP from other people?

Cheers,
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 002AA18D4825781F_=-- From hartmans@mit.edu Fri Jan 21 04:36:56 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 128F63A693C; Fri, 21 Jan 2011 04:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.812 X-Spam-Level: X-Spam-Status: No, score=-102.812 tagged_above=-999 required=5 tests=[AWL=-0.547, 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 B3zY376E-FHO; Fri, 21 Jan 2011 04:36:55 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 3178D3A6958; Fri, 21 Jan 2011 04:36:55 -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 AB3012021E; Fri, 21 Jan 2011 07:37:54 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C52D9432C; Fri, 21 Jan 2011 07:39:32 -0500 (EST) From: Sam Hartman To: liang.xiaoping@zte.com.cn References: Date: Fri, 21 Jan 2011 07:39:32 -0500 In-Reply-To: (liang xiaoping's message of "Fri, 21 Jan 2011 15:45:41 +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-bounces@ietf.org, Sam Hartman , karp@ietf.org Subject: Re: [karp] Negotiation 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, 21 Jan 2011 12:36:56 -0000 >>>>> "liang" == liang xiaoping writes: >>>>> "liang" == liang xiaoping writes: liang> What you pointed out in the email is very importment, and liang> negotiation directly for routers in current use without more liang> work will DO introduce risks, and even bring out severe >> Are there other significant advantages in the KARP context? liang> Yes. In section 1.1 of the document threats-reqs-01, it says liang> that "A KMP is helpful because it negotiates unique, pair liang> wise, random keys without administrator involvement. It also liang> negotiates as mentioned earlier several of the SA parameters liang> required for the secure connection, including key life times. liang> It keeps track of those lifetimes using counters, and liang> negotiates new keys and parameters before they expire, again, liang> without administrator interaction. Additionally, in the liang> event of a breach, changing the KMP key will immediately liang> cause a rekey to occur for the Traffic Key, and those new liang> Traffic Keys will be installed and used in the current liang> connection." I find that paragraph kind of muddled because it combines the advantages of negotiation with the advantages of the KMP. I think we're at least chartered to believe that having a KMP is good. I understand there are participants who disagree with that, but I think we're beyond that argument. So, I think fresh traffic keys, managing SA lifetimes and easier rekeying are inherent properties of a KMP and are not effects of negotiation. >From the above I do see one advantage specific to negotiation: dealing with overlapping parameters that are not identical. That is, if one side permits algorithm A and B, but the other side permis B and C, then the connection can take place with B. Without negotiation, the configuration will need to be exactly in sync. I would love to hear from operators to what extent this is actually an advantage. From liang.xiaoping@zte.com.cn Fri Jan 21 05:18: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 057A13A6967; Fri, 21 Jan 2011 05:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.404 X-Spam-Level: X-Spam-Status: No, score=-99.404 tagged_above=-999 required=5 tests=[AWL=2.434, 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 jwp1j1ADikyu; Fri, 21 Jan 2011 05:18:10 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 2721D3A6920; Fri, 21 Jan 2011 05:18:09 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205952175658078; Fri, 21 Jan 2011 21:16:28 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 53678.3208842533; Fri, 21 Jan 2011 21:13:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p0LDKkJe082729; Fri, 21 Jan 2011 21:20:46 +0800 (GMT-8) (envelope-from liang.xiaoping@zte.com.cn) In-Reply-To: To: Sam Hartman MIME-Version: 1.0 X-KeepSent: 7FEFF379:C3072B97-4825781F:004629E5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: liang.xiaoping@zte.com.cn Date: Fri, 21 Jan 2011 21:20:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-21 21:20:48, Serialize complete at 2011-01-21 21:20:48 Content-Type: multipart/alternative; boundary="=_alternative 0049501B4825781F_=" X-MAIL: mse01.zte.com.cn p0LDKkJe082729 Cc: karp-bounces@ietf.org, karp@ietf.org Subject: Re: [karp] Negotiation 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, 21 Jan 2011 13:18:12 -0000 This is a multipart message in MIME format. --=_alternative 0049501B4825781F_= Content-Type: text/plain; charset="US-ASCII" >>>>> "liang" == liang xiaoping writes: >>>>> "liang" == liang xiaoping writes: liang> What you pointed out in the email is very importment, and liang> negotiation directly for routers in current use without more liang> work will DO introduce risks, and even bring out severe >> Are there other significant advantages in the KARP context? liang> Yes. In section 1.1 of the document threats-reqs-01, it says liang> that "A KMP is helpful because it negotiates unique, pair liang> wise, random keys without administrator involvement. It also liang> negotiates as mentioned earlier several of the SA parameters liang> required for the secure connection, including key life times. liang> It keeps track of those lifetimes using counters, and liang> negotiates new keys and parameters before they expire, again, liang> without administrator interaction. Additionally, in the liang> event of a breach, changing the KMP key will immediately liang> cause a rekey to occur for the Traffic Key, and those new liang> Traffic Keys will be installed and used in the current liang> connection." Sam> I find that paragraph kind of muddled because it combines the advantages Sam> of negotiation with the advantages of the KMP. I think we're at least Sam> chartered to believe that having a KMP is good. I understand there are Sam> participants who disagree with that, but I think we're beyond that Sam> argument. I agree that having a KMP is good, since there is a market demand, and KMP is more advantageous than manual keying, and can remove some problems occurred in manual keying. In my personal opinion, negotiation is one function or ability/capability of KMP, and is very important to automated KMP, especially in secure channel establishment. Sam> So, I think fresh traffic keys, managing SA lifetimes and easier Sam> rekeying are inherent properties of a KMP and are not effects of Sam> negotiation. In essence, yes. Could KMP make these properties reality without negotiation? Negotiation makes KMP more powerful and realize those properties at least. Sam> From the above I do see one advantage specific to negotiation: dealing Sam> with overlapping parameters that are not identical. That is, if one side Sam> permits algorithm A and B, but the other side permis B and C, then the Sam> connection can take place with B. Sam> Without negotiation, the configuration will need to be exactly in sync. Yes, that is one aspect of algorithms agility, and negotiation makes configuration more easy and flexible. Sam> I would love to hear from operators to what extent this is actually an Sam> advantage. Me, too ^_^ Cheers, 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 0049501B4825781F_= Content-Type: text/html; charset="US-ASCII"

>>>>> "liang" == liang xiaoping <liang.xiaoping@zte.com.cn> writes:

>>>>> "liang" == liang xiaoping <liang.xiaoping@zte.com.cn> writes:

   liang> What you pointed out in the email is very importment, and
   liang> negotiation directly for routers in current use without more
   liang> work will DO introduce risks, and even bring out severe
   >> Are there other significant advantages in the KARP context?
   liang> Yes. In section 1.1 of the document threats-reqs-01, it says
   liang> that "A KMP is helpful because it negotiates unique, pair
   liang> wise, random keys without administrator involvement.  It also
   liang> negotiates as mentioned earlier several of the SA parameters
   liang> required for the secure connection, including key life times.
   liang> It keeps track of those lifetimes using counters, and
   liang> negotiates new keys and parameters before they expire, again,
   liang> without administrator interaction.  Additionally, in the
   liang> event of a breach, changing the KMP key will immediately
   liang> cause a rekey to occur for the Traffic Key, and those new
   liang> Traffic Keys will be installed and used in the current
   liang> connection."

Sam> I find that paragraph kind of muddled because it combines the advantages
Sam> of negotiation with the advantages of the KMP.  I think we're at least
Sam> chartered to believe that having a KMP is good. I understand there are
Sam> participants who disagree with that, but I think we're beyond that
Sam> argument.
I agree that having a KMP is good, since there is a market demand, and KMP is more advantageous than manual keying, and can remove some problems occurred in manual keying.

In my personal opinion, negotiation is one function or ability/capability of KMP, and is very important to automated KMP, especially in secure channel establishment.  

Sam> So, I think fresh traffic keys, managing SA lifetimes and easier
Sam> rekeying are inherent properties of a KMP and are not effects of
Sam> negotiation.
In essence, yes. Could KMP make these properties reality without negotiation? Negotiation makes KMP more powerful and realize those properties at least.      

Sam> From the above I do see one advantage specific to negotiation: dealing
Sam> with overlapping parameters that are not identical. That is, if one side
Sam> permits algorithm A and B, but the other side permis B and C, then the
Sam> connection can take place with B.
Sam> Without negotiation, the configuration will need to be exactly in sync.
Yes, that is one aspect of algorithms agility, and negotiation makes configuration more easy and flexible.

Sam> I would love to hear from operators to what extent this is actually an
Sam> advantage.

Me, too ^_^
Cheers,
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 0049501B4825781F_=-- From hartmans@mit.edu Fri Jan 21 06:11: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 610A73A6990; Fri, 21 Jan 2011 06:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.796 X-Spam-Level: X-Spam-Status: No, score=-102.796 tagged_above=-999 required=5 tests=[AWL=-0.531, 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 oj+kGs1PToAl; Fri, 21 Jan 2011 06:11:07 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 511823A68E5; Fri, 21 Jan 2011 06:11:06 -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 B24E92021E; Fri, 21 Jan 2011 09:12:01 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 21334432C; Fri, 21 Jan 2011 09:13:37 -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> Date: Fri, 21 Jan 2011 09:13:37 -0500 In-Reply-To: <4D372F7B.9030507@cisco.com> (Michael Barnes's message of "Wed, 19 Jan 2011 10:37:47 -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: Fri, 21 Jan 2011 14:11:16 -0000 >>>>> "Michael" == Michael Barnes writes: Michael> Hi Sam, Michael> On 01/19/2011 10:13 AM, Sam Hartman wrote: >>>>>>> "Michael" == Michael Barnes writes: >> Michael> Hi Sam, Michael> On 01/14/2011 04:34 AM, Sam Hartman wrote: >> >> We could have separate authentication challenge packets. >> >> However, the advantage of the current approach is that I think we >> >> can get to a point where we have one or two extra packets >> total >> for a cold-start situation, rather than an extra packet >> or two >> per neighbor. I don't know that the current rules for >> receiving >> and sending packets actually achieve this, but I >> believe we can >> get there with some minor changes. >> Michael> I've been giving this some thought, and I think exchanging Michael> a couple of additional packets in the cold start situation Michael> is more desirable than overloading the Hello packet with an Michael> additional security role. The Hello packet already services Michael> two very important purposes - discovery and keep alive. It Michael> is highly desirable not to add to the processing overhead Michael> for these packets. >> >> I'd like to understand your concerns here. Are you concerned >> about CPU for processing the hello packet? Bandwidth of the hello >> packets? I'd like to actually get educated about the tradeoffs >> enough that I can have an intelligent discussion. Michael> I don't think the bandwidth is really an issue, but CPU Michael> is. It is important that processing of these packets can be Michael> completed as quickly as possible. We are constantly being Michael> asked to scale to ever larger number of neighbors and Michael> adding overhead to Hello packets could make this security Michael> mechanism undesirable in those settings. So, I don't think we can avoid a bit of overhead when we are bringing up a new neighbor association: we're trying to do new things in that situation. I've thought about it and the overhead in that situation of having the exchange in the hello is less than with extra challenge response packets. So, we're left with the question of what's the overhead when we already have a neighbor relationship That's the common path and so it is our primary goal for optimization. I went to read the description of receiver behavior in the draft to confirm my understanding of what the overhead is. I found a bug: it turns out that the behavior of hello packets for neighbors in two-way or greater is unspecified. It's intended to be the same as the behavior for non-hello packets. So, let's look at what that behavior is: If a packet other than a hello is received with the new cryptographic authentication option, it must correspond to an existing neighbor relationship in at least the 2-way state. If the neighbor is not in 2-way state or greater, the packet is discarded. If the session ID does not match the session ID recorded with the neighbor, the packet is discarded. If the sequence number in the cryptographic authentication option is not strictly greater than the sequence number associated with the neighbor, then the packet is discarded. If the cryptographic verification of the checksum fails, the packet is discarded. Otherwise, the packet is accepted by the cryptographic authentication and the sequence number associated with the neighbor is updated to be the sequence number in the packet. So, if we update that first sentence to say that section applies to all packets where the neighbor is in 2-way state or greater, we get correct behavior. So, what new overhead do we need? First, we need a compare against the neighbor state; if it is not 2-way or greater, we need to go to a less optimal path. Then we need to compare the session ID. That's the only new behavior. We change the sequence number check from greater than or equal to to strictly greater than, but on all hardware I'm aware of, that's the same performance. So, we've added two operations to the reception of packets for existing neighbors. The operations can be executed in parallel. On a general purpose CPU, both operations would be single instructions. My opinion is that is likely to be acceptable to any environment where cryptographic authentication is acceptable. Note that while we send additional information in a hello packet, we only need to look at that information when setting up a new neighbor. So, let's take a look at what we've done to sending a hello packet because that's also a common operation. We've added two items of state for each neighbor: the session ID and nonce. I guess copying these values into a constructed outgoing packet could be considered per-neighbor overhead. However, an implementation could choose to construct the neighbor list of the outgoing hello packet and store it in a buffer, updating only when the neighbor list changes. So, there is an implementation strategy that does not change the cost of sending a hello in the steady state. I'll also note that the effort required for the "slow" path (updating set of neighbors) is modest: we're talking about a couple of compares and neighbor structure updates. This conversation has been fairly useful. I've noticed a couple of places where we can optimize receiver behavior to reduce number of packets and to improve convirgence in case of reboot. We might even be able to optimize what locks you're likely to hold when a bit. (I realize that where locks are in a data structure is very implementation dependent, but there are things we can do like minimizing the cases where fields need to be updated that are valuable here.) So, I'll work with the other authors to fix the bug I pointed out above and to improve the receiver behavior. Now that I've thought about the tradeoffs between challenge packets and using the hello, I think that the CPU impact of hello packets will be lower than that of challenge packets. So, my preference is to stick with our original design. From acee@lindem.com Fri Jan 21 15:49: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 32A3E3A6846; Fri, 21 Jan 2011 15:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqiMH05kKg8k; Fri, 21 Jan 2011 15:49:44 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.123]) by core3.amsl.com (Postfix) with ESMTP id D63DE3A683C; Fri, 21 Jan 2011 15:49:43 -0800 (PST) X-Authority-Analysis: v=1.1 cv=pepdxKapwHuwCZNFD5uob2wvham6E+RljB0uXw08FdQ= c=1 sm=0 a=7KbkTIrSPugA:10 a=kj9zAlcOel0A:10 a=vBnH86IIPThSVV33hWu2Vw==:17 a=48vgC7mUAAAA:8 a=5b7MeJAKALJDDtEczfwA:9 a=gZcjEfGRbQyJaOSHrrkA:7 a=_MHDYJI8Xdswdrtt8ZhncZ4m9vMA:4 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=XRpajc112AHNb9aF:21 a=SG2G35AbWBcRcTFk:21 a=vBnH86IIPThSVV33hWu2Vw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.177.132.147 Received: from [75.177.132.147] ([75.177.132.147:55487] helo=[192.168.1.100]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 6A/8B-19545-D3C1A3D4; Fri, 21 Jan 2011 23:52:30 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: <4D2FD840.3040908@cisco.com> Date: Fri, 21 Jan 2011 18:52:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> To: Michael Barnes X-Mailer: Apple Mail (2.1082) Cc: ospf@ietf.org, karp@ietf.org Subject: Re: [karp] [OSPF] 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: Fri, 21 Jan 2011 23:49:45 -0000 Hi Manav, I've finally read this draft and I'm less enamored with it than Michael. = I think the requirement to protect the source address is valid. However, = I think the assumptions regarding sequence number management which are = used to justify the challenge/nouce are flawed.=20 If you tie the sequence number to the clock (which I'd guess most = rational implementations already do), then there is no reason for this = nouncense :^). Even with a 32 sequence number, one could increment it = every 1/10 second and get 13.3 years since the last cold boot. If you = were willing to live with 1 second between sequence number increments, = you'd get 133 years.=20 Furthermore, since a new auth type will be required to protect the = source address, the sequence number could also be extended to 64 bits to = allow for greater precision.=20 Thanks, Acee=20 On Jan 13, 2011, at 11:59 PM, Michael Barnes wrote: > Hello Manav, >=20 > First I want to applaud you and your co-authors for addressing these = security problems for OSPF. Thank you. >=20 > I have some initial questions and comments. >=20 > During the challenge and response are the hello packets sent = immediately to each other or by the standard hello timer? >=20 > During the challenge and response on a broadcast links, are the = packets unicast or multicast? >=20 > Regarding the new format for hello packets, is this format to be used = only during challenge and response, or for all hello packets when this = new form of authentication is enabled? >=20 > RFC2328 defines the AuType field, you've chosen to rename it to = AuthType. I suggest we continue to use AuType for continuity. >=20 > In the figures which illustrate the header and hello packet fields, I = suggest that instead of showing two words as just "Authentication" that = the figure shows the sub-fields. In the context of this specification = those words will have a single definition, so there is no reason to = leave them loosely defined. >=20 > Please describe how LLS will be covered using this new authentication = type. >=20 > Regards, > Michael >=20 >=20 > On 01/12/2011 04:43 PM, Bhatia, Manav (Manav) wrote: >> Hi, >>=20 >> Sam, Dacheng and I have written a small draft attempting to fix the = issues that exist when using OSPFv2 with manual keying. It introduces = two additional variables - the Nonce and the Session ID, that need to be = maintained per neighbor, that will, we believe, fix most issues that = currently exist as described in RFC 6039. >>=20 >> As per the KARP design guide we first need to fix the manual keying = before we move to a fully automated key management system for the = routing protocols. This draft attempts to address the first part, i.e., = fixes the issues that exist when using manual keying for OSPF. >>=20 >> It would be great to hear the feedback from the WG. >>=20 >> = http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protection-01.txt >>=20 >> Cheers, Manav >>=20 >> -- >> Manav Bhatia, >> IP Division, Alcatel-Lucent, >> Bangalore - India >>=20 >>=20 >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp >>=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From glen.kent@gmail.com Fri Jan 21 16:50: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 B5D413A6864; Fri, 21 Jan 2011 16:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=0.448, 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 rutqj+5G4CaB; Fri, 21 Jan 2011 16:50:06 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 29FDB3A685D; Fri, 21 Jan 2011 16:50:02 -0800 (PST) Received: by ewy8 with SMTP id 8so1288343ewy.31 for ; Fri, 21 Jan 2011 16:52:48 -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=IrUL8StJ4uOMq/fi0gdj8h9h7Ja8WNE2vWybT6TnqoM=; b=Sr9tA1yKvFak9vv1+pekJmaClUA+U8hMSMjOOeRtTCqVK+psS4zmCD3R452KUnJJ/F A4JZncRdGeaO2Kk1G8jP5tNRLDoaxufbNQ8SRkW7pcmlbNENdb7W1+deLn4P79jFY9eF tZ1k1qv6SfoTV7XpBTAzjRFRzpsk59wNyfRCI= 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=lKAxM22SV8txLbndSGOfj0I76DQtxlI4fUM7WFmvsSgC949hkJfKQhmamSJ53o2N6L UTcp4YsnBSH637AbmBXInBInUloNwbY6j7ZmIQKnRUx0BkCbNHG94q7xsgiyGRKhuIGE zVaDXjZrhx1QKN7jv36qr3V4bNK06w4U3DaPk= MIME-Version: 1.0 Received: by 10.14.48.71 with SMTP id u47mr126470eeb.39.1295657568614; Fri, 21 Jan 2011 16:52:48 -0800 (PST) Received: by 10.14.125.146 with HTTP; Fri, 21 Jan 2011 16:52:48 -0800 (PST) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> Date: Sat, 22 Jan 2011 06:22:48 +0530 Message-ID: From: Glen Kent To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ospf@ietf.org, karp@ietf.org Subject: Re: [karp] [OSPF] 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: Sat, 22 Jan 2011 00:50:13 -0000 Hi Acee, Is it reasonable to assume that the router will never reboot (crash, upgrade and maintenance, etc). If it is then i believe this is a better alternative and the authors should consider this. Glen On Sat, Jan 22, 2011 at 5:22 AM, Acee Lindem wrote: > Hi Manav, > > I've finally read this draft and I'm less enamored with it than Michael. = I think the requirement to protect the source address is valid. However, I = think the assumptions regarding sequence number management which are used t= o justify the challenge/nouce are flawed. > If you tie the sequence number to the clock (which I'd guess most rationa= l implementations already do), then there is no reason for this nouncense := ^). =A0Even with a 32 sequence number, one could increment it every 1/10 se= cond and get 13.3 years since the last cold boot. If you were willing to li= ve with 1 second between sequence number increments, you'd get 133 years. > Furthermore, since a new auth type will be required to protect the source= address, the sequence number could also be extended to 64 bits to allow fo= r greater precision. > > Thanks, > Acee > > On Jan 13, 2011, at 11:59 PM, Michael Barnes wrote: > >> Hello Manav, >> >> First I want to applaud you and your co-authors for addressing these sec= urity problems for OSPF. Thank you. >> >> I have some initial questions and comments. >> >> During the challenge and response are the hello packets sent immediately= to each other or by the standard hello timer? >> >> During the challenge and response on a broadcast links, are the packets = unicast or multicast? >> >> Regarding the new format for hello packets, is this format to be used on= ly during challenge and response, or for all hello packets when this new fo= rm of authentication is enabled? >> >> RFC2328 defines the AuType field, you've chosen to rename it to AuthType= . I suggest we continue to use AuType for continuity. >> >> In the figures which illustrate the header and hello packet fields, I su= ggest that instead of showing two words as just "Authentication" that the f= igure shows the sub-fields. In the context of this specification those word= s will have a single definition, so there is no reason to leave them loosel= y defined. >> >> Please describe how LLS will be covered using this new authentication ty= pe. >> >> Regards, >> Michael >> >> >> On 01/12/2011 04:43 PM, Bhatia, Manav (Manav) wrote: >>> Hi, >>> >>> Sam, Dacheng and I have written a small draft attempting to fix the iss= ues that exist when using OSPFv2 with manual keying. It introduces two addi= tional variables - the Nonce and the Session ID, that need to be maintained= per neighbor, that will, we believe, fix most issues that currently exist = as described in RFC 6039. >>> >>> As per the KARP design guide we first need to fix the manual keying bef= ore we move to a fully automated key management system for the routing prot= ocols. This draft attempts to address the first part, i.e., fixes the issue= s that exist when using manual keying for OSPF. >>> >>> It would be great to hear the feedback from the WG. >>> >>> http://www.ietf.org/id/draft-bhatia-karp-ospf-ip-layer-protection-01.tx= t >>> >>> Cheers, Manav >>> >>> -- >>> Manav Bhatia, >>> IP Division, Alcatel-Lucent, >>> Bangalore - India >>> >>> >>> _______________________________________________ >>> karp mailing list >>> karp@ietf.org >>> https://www.ietf.org/mailman/listinfo/karp >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From hartmans@mit.edu Sat Jan 22 12:30:56 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 EA5C23A69C4; Sat, 22 Jan 2011 12:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-0.516, 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 YXGwk3WY-z9o; Sat, 22 Jan 2011 12:30:56 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 202673A6842; Sat, 22 Jan 2011 12:30: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 2D3E720222; Sat, 22 Jan 2011 15:31:55 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CA434432C; Sat, 22 Jan 2011 15:33:30 -0500 (EST) From: Sam Hartman To: Acee Lindem References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> Date: Sat, 22 Jan 2011 15:33:30 -0500 In-Reply-To: (Acee Lindem's message of "Fri, 21 Jan 2011 18:52:29 -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: ospf@ietf.org, karp@ietf.org Subject: Re: [karp] [OSPF] 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: Sat, 22 Jan 2011 20:30:57 -0000 >>>>> "Acee" == Acee Lindem writes: Acee> Hi Manav, I've finally read this draft and I'm less enamored Acee> with it than Michael. I think the requirement to protect the Acee> source address is valid. However, I think the assumptions Acee> regarding sequence number management which are used to justify Acee> the challenge/nouce are flawed. If you tie the sequence Acee> number to the clock (which I'd guess most rational Acee> implementations already do), then there is no reason for this Acee> nouncense :^). Even with a 32 sequence number, one could Acee> increment it every 1/10 second and get 13.3 years since the Acee> last cold boot. If you were willing to live with 1 second Acee> between sequence number increments, you'd get 133 years. Acee> Furthermore, since a new auth type will be required to protect Acee> the source address, the sequence number could also be extended Acee> to 64 bits to allow for greater precision. I think it's fairly obvious that to protect against the replay attacks OSPF needs to require strictly increasing sequence numbers. No matter how small you slice it if two packets are ever sent with the same sequence number, an attacker can do significant damage. That's obviously true for database packets, but is generally true for hellos as well. However, if you are willing to base things on the time, you can have a timestamp plus a packet counter. You give up a few things for that. If you ever need to roll a clock back a significant period, you will lose the adjacency. In addition, you will introduce significant DOS opportunities unless you rekey the link. These will last until the time catches up and becomes greater than any time ever used. You also lose protection against nodes that are down. I'm reasonably sure that you could get a 2-way association up simply by replaying packets. I'd need to think about how the database sequence numbers are generated to understand whether you could actually manage to inject a route with replays from a down node. You could defend against this by requiring that the clocks be synchronized within some period, not just strictly increasing. So, yes, there are simpler options than a challenge/response protocol if you are willing to require clocks loosely synchronized to real time. From ShraddhaH@huawei.com Sun Jan 23 22:18: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 4E0513A6A74; Sun, 23 Jan 2011 22:18:45 -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 cgxQkGwomCkD; Sun, 23 Jan 2011 22:18:44 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 354983A68AF; Sun, 23 Jan 2011 22:18:44 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFI00J06KBOUG@szxga03-in.huawei.com>; Mon, 24 Jan 2011 14:21:24 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFI00AGGKBOE4@szxga03-in.huawei.com>; Mon, 24 Jan 2011 14:21:24 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFI00I4MKBN90@szxml06-in.huawei.com>; Mon, 24 Jan 2011 14:21:24 +0800 (CST) Date: Mon, 24 Jan 2011 11:51:22 +0530 From: shraddha To: hartmans-ietf@mit.edu Message-id: <0A01246AA6CE467884E50D36E6BABCCA@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acu7juvieG0XVoCqSnaXIXjmTKvKcQ== Cc: ospf@ietf.org, karp@ietf.org Subject: [karp] Security Extension for OSPFv2 when using Manual Key Management X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ShraddhaH@huawei.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: Mon, 24 Jan 2011 06:18:45 -0000 Hi Sam, In section 2, while explaining the challenge response solution For a new router coming up on the LAN is described, a router changes it's Nonce when it detects a new node on the LAN. 1. This feature can be used to launch DOS attacks and cause a router to change the nonce continuously. However I cannot think of a completely secure solution to avoid DOS but introducing a minimum time (Similar to MinLSArrival) to change the nonce might be helpful to reduce the effect. 2. When a node detects change in the nonce in a hello message, it might have to send hello immediately to ensure it's adjacency as it's some of the previous hellos might be dropped by the router which changed the nonce. This can be mentioned explicitly in the Receive packet handling section. 3. As I understand, the nonce is not checked for messages other than hello so it can be removed from the trailer for other messages? Rgds Shraddha **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From hartmans@mit.edu Mon Jan 24 05:30: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 174E93A687A; Mon, 24 Jan 2011 05:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.501, 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 lcENemcEKkLU; Mon, 24 Jan 2011 05:30:52 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 039F63A6AC3; Mon, 24 Jan 2011 05:30:51 -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 2A67B20222; Mon, 24 Jan 2011 08:31:52 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B8186432C; Mon, 24 Jan 2011 08:33:25 -0500 (EST) From: Sam Hartman To: ShraddhaH@huawei.com References: <0A01246AA6CE467884E50D36E6BABCCA@china.huawei.com> Date: Mon, 24 Jan 2011 08:33:25 -0500 In-Reply-To: <0A01246AA6CE467884E50D36E6BABCCA@china.huawei.com> (shraddha's message of "Mon, 24 Jan 2011 11:51:22 +0530") 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: ospf@ietf.org, hartmans-ietf@mit.edu, karp@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: Mon, 24 Jan 2011 13:30:53 -0000 >>>>> "shraddha" == shraddha writes: shraddha> Hi Sam, In section 2, while explaining the challenge shraddha> response solution For a new router coming up on the LAN is shraddha> described, a router changes it's Nonce when it detects a shraddha> new node on the LAN. shraddha> 1. This feature can be used to launch DOS attacks and shraddha> cause a router to change the nonce continuously. However I shraddha> cannot think of a completely secure solution to avoid DOS shraddha> but introducing a minimum time (Similar to MinLSArrival) shraddha> to change the nonce might be helpful to reduce the effect. It's not actually changing the nonce that is problematic; it is sending hello packets with the new nonce. Yes, you can introduce a minimum time between hello packets to fix this. shraddha> 2. When a node detects change in the nonce in a hello shraddha> message, it might have to send hello immediately to ensure shraddha> it's adjacency as it's some of the previous hellos might shraddha> be dropped by the router which changed the nonce. This shraddha> can be mentioned explicitly in the Receive packet handling I shraddha> section. I'm not sure you need to check nonces for hellos for things in 2-way or greater. So I don't think this is a concern. shraddha> 3. As I understand, the nonce is not checked for messages shraddha> other than hello so it can be removed from the trailer for shraddha> other messages? Yep. shraddha> Rgds Shraddha shraddha> **************************************************************************** shraddha> *********** This e-mail and attachments contain shraddha> confidential information from HUAWEI, which is intended shraddha> only for the person or entity whose address is listed shraddha> above. Any use of the information contained herein in any shraddha> way (including, but not limited to, total or partial shraddha> disclosure, reproduction, or dissemination) by persons shraddha> other than the intended recipient's) is prohibited. If you shraddha> receive this e-mail in error, please notify the sender by shraddha> phone or email immediately and delete it! From ShraddhaH@huawei.com Thu Jan 27 01:20: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 A069428C10E for ; Thu, 27 Jan 2011 01:20:14 -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 2t+oUXn3AB-7 for ; Thu, 27 Jan 2011 01:20:12 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A58E628B23E for ; Thu, 27 Jan 2011 01:20:12 -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 <0LFO00F8GCQC1N@szxga04-in.huawei.com> for karp@ietf.org; Thu, 27 Jan 2011 17:23:00 +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 <0LFO005IMCQCM2@szxga04-in.huawei.com> for karp@ietf.org; Thu, 27 Jan 2011 17:23:00 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFO00LTYCQBK2@szxml04-in.huawei.com> for karp@ietf.org; Thu, 27 Jan 2011 17:23:00 +0800 (CST) Date: Thu, 27 Jan 2011 14:52:58 +0530 From: shraddha To: karp@ietf.org Message-id: <79425ED37641499098922AB783C4FA30@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acu+A8mK8awZaQ2+TxS4njUsbBHJwQ== Subject: [karp] KMP and IPSEC X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ShraddhaH@huawei.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, 27 Jan 2011 09:20:14 -0000 Hi All, I have recently joined the KARP mailing list and have gone through The drafts and work in progress. I could not understand the choice of new KMP framework for routing protocols rather than using IPSEC 1. From some of the previous archives I could get information that the major concern for not using IPSEC is the multicast traffic that needs to be protected in routing protocols. 2. There is significant work going on in MSEC group and the new drafts and RFCs address securing multicast traffic along with dynamic keying. RFC 5374 even addresses the anti-replay mechanisms to be followed for multicast packets. 3. The KMP framework drafts also propose to use IKEv2 for dynamic key negotiation. IKE and IPSEC always go together and there may be less possibility of only IKE available on a router without IPSEC. Since we already have a security framework in terms of IPSEC available, which can mostly handle all the security requirements, is there a need to come up with new key management framework for the routing protocols?. The new KMP also depends on IKE for the node authentication which has to be either Pre-shared key or the PKI based authentication so all the issues related to PSK (less scalable and manageable) and PKI (high cost infrastructure and third party software) remain open, which might have been the reasons for the delayed deployment of IPSEC in the backbone networks. The only advantage I can think of, for the separate KMP for routing protocols is > The ease of controlling the SA granularity based on native protocol. > May be new KMP will reduce some small amount of memory overheads In terms of maintaining the SAs The above two advantages look negligible in terms of ROI of implementing new framework. Some one can suggest if my understandings are correct or I have missed something. Thanks Shraddha **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From mark.ietf@gmail.com Thu Jan 27 16:24:30 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 EDFF33A6B12 for ; Thu, 27 Jan 2011 16:24:29 -0800 (PST) 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 yi6-Y32Si+wO for ; Thu, 27 Jan 2011 16:24:28 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id BF4B23A6AFD for ; Thu, 27 Jan 2011 16:24:25 -0800 (PST) Received: by qyj19 with SMTP id 19so2887679qyj.10 for ; Thu, 27 Jan 2011 16:27:30 -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=A/IjnRVeg6T1Iz6XP5SyKKqikv3NFqD2m57bZ02oqSc=; b=lzkCY0QORl4aotCNgW9oK8Xwc/JifU5/vwGb+BLmi263NLbNdhuOgMy0VGdC35SAYT kJikgbQ/rFiNnhBDNcXWdU6q39nR3xEY3tUEHKteQ7CBOS1Oz4VIN47SMR9HngA1K3Z9 nh48lWiNoZVWJf3gNPvPM0My0BwfkNJkEzQi4= 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=HRDaz8r7LutUhLWsgDd53WT5oJp3Vi3CTzD6S57aek7PVhVVBGgVVnMDdqVDwHuq3o SvKLX63fsmaw754ToONT5LCiirxKze8L2LJBM3hH053Hs94nGlbWgrHFKTLKFRliWaGz bPNn+EkZkIY5dMKOrfiSD1WctzbbX5p0122DA= MIME-Version: 1.0 Received: by 10.229.251.137 with SMTP id ms9mr2103312qcb.188.1296174450042; Thu, 27 Jan 2011 16:27:30 -0800 (PST) Received: by 10.229.222.73 with HTTP; Thu, 27 Jan 2011 16:27:29 -0800 (PST) In-Reply-To: <79425ED37641499098922AB783C4FA30@china.huawei.com> References: <79425ED37641499098922AB783C4FA30@china.huawei.com> Date: Fri, 28 Jan 2011 05:57:29 +0530 Message-ID: From: mark Brown To: ShraddhaH@huawei.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: karp@ietf.org Subject: Re: [karp] KMP and IPSEC 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, 28 Jan 2011 00:24:30 -0000 Shraddha, The WG has not yet concluded on whether it wants to define a new KMP for routing protocols or wants to continue with using IPsec for the same. Mark On Thu, Jan 27, 2011 at 2:52 PM, shraddha wrote: > > Hi All, > > I have recently joined the KARP mailing list and have gone through > The drafts and work in progress. > > I could not understand the choice of new KMP framework for routing protoc= ols > rather than using IPSEC > > 1. From some of the previous archives I could get information that the ma= jor > concern for not using IPSEC is the multicast traffic that needs to be > protected in routing protocols. > > 2. There is significant work going on in MSEC group and the new drafts an= d > RFCs address securing multicast traffic along with dynamic keying. > RFC 5374 even addresses the anti-replay mechanisms to be followed for > multicast packets. > > 3. The KMP framework drafts also propose to use IKEv2 for dynamic key > negotiation. IKE and IPSEC always go together and there may be less > possibility of only IKE available on a router without IPSEC. > > Since we already have a security framework in terms of IPSEC available, > which can mostly handle all the security requirements, is there a need to > come up with new key management framework for the routing protocols?. > > The new KMP also depends on IKE for the node authentication which has to = be > either Pre-shared key or the PKI based authentication so all the issues > related to PSK =A0(less scalable and manageable) and PKI (high cost > infrastructure and third party software) remain open, which might have be= en > the reasons for the delayed deployment of IPSEC in the backbone networks. > > The only advantage I can think of, for the separate KMP for routing > protocols is >> The ease of controlling the SA granularity based on native protocol. >> May be new KMP will reduce some small amount of memory overheads > =A0In terms of maintaining the SAs > > The above two advantages look negligible in terms of ROI of implementing = new > framework. > > Some one can suggest if my understandings are correct or I have missed > something. > > > Thanks > Shraddha > > > *************************************************************************= *** > *********** > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender= by > phone or email immediately and delete it! > > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From acee@lindem.com Sun Jan 30 12:09: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 127063A6853; Sun, 30 Jan 2011 12:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7Gm12locJtJ; Sun, 30 Jan 2011 12:09:42 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by core3.amsl.com (Postfix) with ESMTP id 04AF83A6851; Sun, 30 Jan 2011 12:09:41 -0800 (PST) X-Authority-Analysis: v=1.1 cv=pepdxKapwHuwCZNFD5uob2wvham6E+RljB0uXw08FdQ= c=1 sm=0 a=7KbkTIrSPugA:10 a=kj9zAlcOel0A:10 a=vBnH86IIPThSVV33hWu2Vw==:17 a=EPTKzkUpDcBdCqvOhHQA:9 a=nuE25qpi61mkifkz7Y_bNEMzyg8A:4 a=CjuIK1q_8ugA:10 a=flFrafPoSo6mzfE2:21 a=BKKMvkn3aOTIs_D9:21 a=vBnH86IIPThSVV33hWu2Vw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 75.177.132.147 Received: from [75.177.132.147] ([75.177.132.147:64801] helo=[192.168.1.100]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id EF/67-19545-546C54D4; Sun, 30 Jan 2011 20:12:54 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Sun, 30 Jan 2011 15:12:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> To: Jack Kohn X-Mailer: Apple Mail (2.1082) Cc: ospf@ietf.org, karp@ietf.org Subject: Re: [karp] [OSPF] 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: Sun, 30 Jan 2011 20:09:43 -0000 On Jan 30, 2011, at 12:55 PM, Jack Kohn wrote: > Acee: >=20 >> I've finally read this draft and I'm less enamored with it than = Michael. I think the > >> requirement to protect the source address is valid. However, I think = the assumptions >=20 > Yes, i agree and there has been a discussion that this should be done. >=20 >> regarding sequence number management which are used to justify the = challenge/nouce >> are flawed. >=20 > And why do you think this is flawed? >=20 >> If you tie the sequence number to the clock (which I'd guess most = rational >> implementations already do), then there is no reason for this = nouncense :^). Even with a >=20 > You should not tie anything to the clock since the time can go back. > This is also one reason why we dont use the clock to give us the > sequence numbers for regular OSPF and IS-IS. I wasn't suggesting using the time of day clock but the system clock = (which will never go backwards and is required for other reasons).=20 However, I can see that a patient enough attacker could simply wait for = a cold start using the same manual key.=20 Given how much extra signaling and complexity is required in this = solution, it may better to wait for a solution to the manual keying = problem. =20 Acee=20 >=20 > Jack From kohn.jack@gmail.com Sun Jan 30 09:52:21 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 1FBBF3A684E; Sun, 30 Jan 2011 09:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.326, 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 ZAYhyB-SNbac; Sun, 30 Jan 2011 09:52:19 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 5C6213A6834; Sun, 30 Jan 2011 09:52:19 -0800 (PST) Received: by iyi42 with SMTP id 42so4576339iyi.31 for ; Sun, 30 Jan 2011 09:55:31 -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=0UqizkrIXnOY4EJjLm/4YwoXduW5n4qmaZT+o2tU+DE=; b=gkEBIQYQNi+tAl3re3ShMAP0nu5Ksorfy0iXjn+4My2gEfepL6brJjxN1dK4nSKaCj szeslOFlkBua2dIe0wcIrE006POH4+eSrxFISUi0gMnpXqLX2EKyHHT2tVcgKJJjp1+e QIwFj6XJ+hT0bIa2JS5+QHr5WbffSCxVhZOk4= 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=MTU1X40brelHXWlnGHJLpgoP7OUzLb91YV2cZeZyMzpJ1aboUjOQTwCb4tAKPUgTnd 3CjMvFxGwAbShFiAXgybMVjSaDdhpYzwLlMoEZqjvi5RxdnwlWhsk38LwoqBzt2snQS3 TJ1WmFuzKFyZALO5/P9Xkx46kIilBO/FOQiOM= MIME-Version: 1.0 Received: by 10.231.199.19 with SMTP id eq19mr5470836ibb.175.1296410131315; Sun, 30 Jan 2011 09:55:31 -0800 (PST) Received: by 10.231.200.148 with HTTP; Sun, 30 Jan 2011 09:55:31 -0800 (PST) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350CFB03C880@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D2FD840.3040908@cisco.com> Date: Sun, 30 Jan 2011 23:25:31 +0530 Message-ID: From: Jack Kohn To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 30 Jan 2011 17:45:00 -0800 Cc: ospf@ietf.org, karp@ietf.org Subject: Re: [karp] [OSPF] 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: Sun, 30 Jan 2011 17:52:21 -0000 Acee: > I've finally read this draft and I'm less enamored with it than Michael. = I think the > > requirement to protect the source address is valid. However, I think the = assumptions Yes, i agree and there has been a discussion that this should be done. > regarding sequence number management which are used to justify the challe= nge/nouce > are flawed. And why do you think this is flawed? > If you tie the sequence number to the clock (which I'd guess most rationa= l > implementations already do), then there is no reason for this nouncense := ^). =A0Even with a You should not tie anything to the clock since the time can go back. This is also one reason why we dont use the clock to give us the sequence numbers for regular OSPF and IS-IS. Jack