From kent@bbn.com Fri Apr 1 00:40:55 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F763A6BFA for ; Fri, 1 Apr 2011 00:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtuAfuvOUeLP for ; Fri, 1 Apr 2011 00:40:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 315A33A6BFB for ; Fri, 1 Apr 2011 00:40:55 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58222 helo=[130.129.20.213]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5Z06-000Hjt-Se; Fri, 01 Apr 2011 03:42:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 1 Apr 2011 03:27:40 -0400 To: "Spies, Sebastian Martin" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] draft-ietf-sidr-roa-format ASN1-format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:40:55 -0000 At 11:47 AM -0400 3/31/11, Spies, Sebastian Martin wrote: >The AFI of ROAIPAddress (defined in 3. The ROA eContent of >draft-ietf-sidr-roa-format) is of type OCTET STRING (SIZE (2..3)). >For which reason is it necessary to have a variable AFI size? We are >having just two values 0001 and 0002 and it is unlikely to see new >address families at a count that exceeds 2^16. So why should there >be a third byte? > >---- >Sebastian Spies RFC 2858 defines AFI as 2 bytes, and the optional SAFI as one more byte. That's why RFC 3779 defines a 2-3 byte data element for this pair. The ROA syntax inherits that structure. Steve From randy@psg.com Fri Apr 1 04:22:04 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90AE73A680B for ; Fri, 1 Apr 2011 04:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 mGlz8Nqwe+07 for ; Fri, 1 Apr 2011 04:22:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id D7D773A6811 for ; Fri, 1 Apr 2011 04:22:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-2643.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5cQt-000IKE-AQ; Fri, 01 Apr 2011 11:22:27 +0000 Date: Fri, 01 Apr 2011 13:22:26 +0200 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 11:22:04 -0000 i propose that i rev the doc to say o the transport must provide authentication and integrity o the current ssh description is an example o other transport meeting the authentication and integrity constraints are welcome of course, this will leave open the mandatory-to-implement LCD issue. sigh. randy From jared@puck.nether.net Fri Apr 1 04:39:53 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887E83A6836 for ; Fri, 1 Apr 2011 04:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 0VMXi9lDSK19 for ; Fri, 1 Apr 2011 04:39:53 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id 729DA3A6834 for ; Fri, 1 Apr 2011 04:39:52 -0700 (PDT) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p31BfSpT016940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Apr 2011 07:41:29 -0400 (EDT) (envelope-from jared@puck.nether.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Fri, 1 Apr 2011 07:41:28 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Fri, 01 Apr 2011 07:41:29 -0400 (EDT) Cc: Christopher Morrow , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 11:39:53 -0000 On Apr 1, 2011, at 7:22 AM, Randy Bush wrote: > i propose that i rev the doc to say > o the transport must provide authentication and integrity > o the current ssh description is an example > o other transport meeting the authentication and integrity constraints > are welcome This sounds acceptable to me. - Jared > of course, this will leave open the mandatory-to-implement LCD issue. > sigh. From andrei.robachevsky@gmail.com Fri Apr 1 05:36:56 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD05E28C1D1 for ; Fri, 1 Apr 2011 05:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GbgeLnYWl7N for ; Fri, 1 Apr 2011 05:36:56 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 09C3F28C751 for ; Fri, 1 Apr 2011 05:35:43 -0700 (PDT) Received: by bwz13 with SMTP id 13so2701249bwz.31 for ; Fri, 01 Apr 2011 05:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=K34Wg8yOVMJOhL9cYiBq//jFaebTxGmbp7qwS6RxpRU=; b=EBu7CQKvJwLhEHUZDcgmg9qlAWjXfJ90FPkArDllZnTTmDl+CpFEaf5ogwEowKdf98 LQCMDwmYJPf79TpEg31j7+639vfe+6PlUMonKonhd2P78c2wK4GpTumFQQMOxn+PQFkh tP9rxaWijU9qU2Do8uMS6iCRZQi9L+pFqK68U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=Da3CgJ6BrKF+b+Platzm+E9EKxd39/8nGT27V32kleohSNoWYQYSPXke9vPV0/dDcW X7o+UFiMosxs5Ur1ClY5kZnS2NGsqNCiAYPLz3EV3f4gdJbAPwomU9aN7DMERJS+KyMH plGnyXKxrCOmLcHvFmv1kghrPMtghr4uHOwEg= Received: by 10.204.20.139 with SMTP id f11mr184391bkb.177.1301661443751; Fri, 01 Apr 2011 05:37:23 -0700 (PDT) Received: from dhcp-530a.meeting.ietf.org (dhcp-530a.meeting.ietf.org [130.129.83.10]) by mx.google.com with ESMTPS id b6sm1377118bkb.10.2011.04.01.05.37.22 (version=SSLv3 cipher=OTHER); Fri, 01 Apr 2011 05:37:22 -0700 (PDT) Message-ID: <4D95C701.9010308@gmail.com> Date: Fri, 01 Apr 2011 14:37:21 +0200 From: Andrei Robachevsky User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sidr] suggested amendment to draft-ymbk-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 12:36:56 -0000 Hi, I propose the inclusion of the following requirement: 3.x A BGPsec design should not decrease the performance characteristics of the BGP, nor have a negative impact on the overall resilience of the routing system. Examples that I have in mind is the convergence time or a solution that can make the global routing system more fragile (e.g. an expired signature blacking out a significant part of the Internet). Perhaps that should also be covered in the deployment considerations, since this depends partly on local policy decisions. Andrei From jhaas@slice.pfrc.org Fri Apr 1 06:10:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B677E3A683E for ; Fri, 1 Apr 2011 06:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.075, 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 cqjKRQEdnp1C for ; Fri, 1 Apr 2011 06:10:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 441683A6767 for ; Fri, 1 Apr 2011 06:10:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 85DEA224235; Fri, 1 Apr 2011 13:11:42 +0000 (UTC) Date: Fri, 1 Apr 2011 13:11:42 +0000 From: Jeffrey Haas To: sidr@ietf.org Message-ID: <20110401131142.GA15519@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [sidr] IETF 80 - suggestions related to expiry time and BGP implementation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:10:02 -0000 Per the microphone at SIDR on Friday: 1. Text should be added to strongly recommend that when a route that is about to expire is having an update of the expiration advertised that receiving peers should treat the reception of an update with no other changes to the reachability than the expiration time and signatures as a refresh of the existing route. Implementations supporting temporal time breaking in path selection should *not* treat the refresh as a new update. 2. Short expiry times are an attack on the routing system, especially boxes with slow signature processors. Routes that will expire "soon" should be refreshed with enough time so that receiving peers can take their own sweet time to validate that a new valid path has been received in spare cycles. Note that I realize that it is difficult to distinguish between a refresh vs. an update. Suggestion 2 may make poor cryptographic protocol sense. This effectively has BGP holding onto a stale announcement for a period of time until it has validated the route. -- Jeff From jgs@juniper.net Fri Apr 1 06:32:24 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C8B3A6856 for ; Fri, 1 Apr 2011 06:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 gZbQHP3-zQv1 for ; Fri, 1 Apr 2011 06:32:23 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 89D4D3A6889 for ; Fri, 1 Apr 2011 06:31:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTZXUED/oE0vVwOUD+5dEpOvY7tg3vQa3@postini.com; Fri, 01 Apr 2011 06:33:09 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 1 Apr 2011 06:31:15 -0700 From: John Scudder To: Randy Bush Date: Fri, 1 Apr 2011 06:32:48 -0700 Thread-Topic: [sidr] WGLC draft-sidr-rpki-rtr - take 2? Thread-Index: AcvwcRNzgwJR365mQyeoRRstFDIb0g== Message-ID: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Christopher Morrow , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:32:24 -0000 On Apr 1, 2011, at 1:22 PM, Randy Bush wrote: > i propose that i rev the doc to say > o the transport must provide authentication and integrity > o the current ssh description is an example > o other transport meeting the authentication and integrity constraints > are welcome >=20 > of course, this will leave open the mandatory-to-implement LCD issue. > sigh. I think we shouldn't punt on a mandatory transport. I suggest TCP-MD5 for = practical reasons, including the open source support issue Chris raised. --John= From dougm.tlist@gmail.com Fri Apr 1 06:34:58 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4805C3A680F for ; Fri, 1 Apr 2011 06:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUQaGoTaXKzR for ; Fri, 1 Apr 2011 06:34:56 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 9BF823A688A for ; Fri, 1 Apr 2011 06:34:13 -0700 (PDT) Received: by bwz13 with SMTP id 13so2745191bwz.31 for ; Fri, 01 Apr 2011 06:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=B++sfg7vW3p/wVIzUlr+kW77KYnpvhRj6ZAr1ouLTOo=; b=B/PEx5vzABply7XuvblfC3jyiGyuRY5NkwTPbUzCZWNdFDo/I1EyJ2yjQi6IpbZEDn xh1x55gtn+3z5v2xrgI28x4K7nMrIaRK+dAlfSI0Wg2EBkOPqwJirIq7okmKJJgdzzEa CqBPWVjL01sZtqKSmTJgXBytG2lSwVAPHDvYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=OQWDLqubgI1huYt3kdLow8HgzkZtY3cF0DSl5KdTRw/jPNhDjY6UZYUifrVgvtGoIr /P8VtDdT51aPz1gRxNlplZ/QpLayDgZfG/GLwbuxAhXMbdgKeUFrRPHkFdJv8Zd0pN+T hNo90AufPBN4eSGk/WPLMn2WW1H5/0htqe4ss= Received: by 10.204.8.141 with SMTP id h13mr1549062bkh.64.1301664953369; Fri, 01 Apr 2011 06:35:53 -0700 (PDT) Received: from dhcp-151a.meeting.ietf.org (dhcp-151a.meeting.ietf.org [130.129.21.26]) by mx.google.com with ESMTPS id q24sm1407900bks.21.2011.04.01.06.35.51 (version=SSLv3 cipher=OTHER); Fri, 01 Apr 2011 06:35:52 -0700 (PDT) Message-ID: <4D95D4B6.9050704@gmail.com> Date: Fri, 01 Apr 2011 09:35:50 -0400 From: Doug Montgomery User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: sidr@ietf.org References: <4D95C701.9010308@gmail.com> In-Reply-To: <4D95C701.9010308@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] suggested amendment to draft-ymbk-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:34:58 -0000 On 4/1/11 8:37 AM, Andrei Robachevsky wrote: > Hi, > > I propose the inclusion of the following requirement: > > 3.x A BGPsec design should not decrease the performance characteristics > of the BGP, nor have a negative impact on the overall resilience of the > routing system. > "should not decrease" seems a bit literal and restrictive. One could argue that no addition of a feature that put more bits on the wire could meet that goal. Maybe the operative requirement is that the performance implications with respect to convergence be clearly defined (in an algorithmic sense (e.g., require 1 RSA/SHA verification per hop, and the addition of x bytes of new attributes per hop). Maybe some follow up bench marking of independent implementations in the protocol report later would further clarify the issue. All other characterizations of larger impacts on convergence will be based upon models ... and more speculative. As for resilience, I think it also key to document what factors might influence resilience issues of BGPSEC operations (e.g., distribution of global RPKI data, etc). One should also note that the goal of this protocol is to improve the resilience of the system ... ;^). As it stands now, BGPSEC is opt-in. So it seems that clearly documenting these issues is more operative than make absolute requirements about them. > Examples that I have in mind is the convergence time or a solution that > can make the global routing system more fragile (e.g. an expired > signature blacking out a significant part of the Internet). Perhaps that > should also be covered in the deployment considerations, since this > depends partly on local policy decisions. > > Andrei > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From iesg-secretary@ietf.org Fri Apr 1 07:55:56 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004443A687F; Fri, 1 Apr 2011 07:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbE6SjJVnC3G; Fri, 1 Apr 2011 07:55:55 -0700 (PDT) Received: from email.elon.edu (efe2.elon.edu [152.33.5.1]) by core3.amsl.com (Postfix) with ESMTP id 051803A6839; Fri, 1 Apr 2011 07:55:54 -0700 (PDT) Received: from EV01.elon.edu ([10.17.1.100]) by email.elon.edu with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Apr 2011 10:57:06 -0400 Received: from mail pickup service by EV01.elon.edu with Microsoft SMTPSVC; Fri, 1 Apr 2011 10:56:11 -0400 Received: from email.elon.edu ([10.17.1.143]) by EV01.elon.edu with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Mar 2011 06:37:49 -0400 Received: from emf1.elon.edu ([10.17.20.20]) by email.elon.edu with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Mar 2011 06:37:49 -0400 X-ASG-Debug-ID: 1301567869-0314c70edf80440001-3cnnEG Received: from mail-iy0-f174.google.com (mail-iy0-f174.google.com [209.85.210.174]) by emf1.elon.edu with ESMTP id RJZDNaUAtNqXCNfL for ; Thu, 31 Mar 2011 06:37:49 -0400 (EDT) X-Barracuda-Envelope-From: ietf-announce-bounces@ietf.org X-Barracuda-Apparent-Source-IP: 209.85.210.174 Received: by iyb14 with SMTP id 14sf3144715iyb.33 for ; Thu, 31 Mar 2011 03:37:48 -0700 (PDT) Received: by 10.43.135.66 with SMTP id if2mr2985396icc.255.1301567868426; Thu, 31 Mar 2011 03:37:48 -0700 (PDT) X-Barracuda-BBL-IP: nil Received: by 10.43.135.66 with SMTP id if2mr2985395icc.255.1301567868417; Thu, 31 Mar 2011 03:37:48 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id xg5si2405027icb.24.2011.03.31.03.37.48; Thu, 31 Mar 2011 03:37:48 -0700 (PDT) Received-SPF: pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=ietf-announce-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7A23A6B33; Thu, 31 Mar 2011 03:36:07 -0700 (PDT) X-Original-To: ietf-announce@core3.amsl.com Delivered-To: ietf-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F66C28C10C; Thu, 31 Mar 2011 03:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 s2p0ZO-oKjlM; Thu, 31 Mar 2011 03:36:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379F93A6B24; Thu, 31 Mar 2011 03:36:05 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: IETF-Announce X-Test-IDTracker: no X-ASG-Orig-Subj: Last Call: (Validation of Route Origination using the Resource Certificate PKI and ROAs) to Informational RFC X-IETF-IDTracker: 3.14 Message-ID: <20110331103605.21654.33101.idtracker@localhost> Date: Thu, 31 Mar 2011 03:36:05 -0700 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org X-Barracuda-Connect: mail-iy0-f174.google.com[209.85.210.174] X-Barracuda-Start-Time: 1301567869 X-Barracuda-URL: http://spam.elon.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at elon.edu X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=2.5 QUARANTINE_LEVEL=3.0 KILL_LEVEL=5.0 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.59494 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain X-OriginalArrivalTime: 31 Mar 2011 10:37:49.0579 (UTC) FILETIME=[AE6AD5B0:01CBEF8F] Cc: sidr@ietf.org Subject: [sidr] Last Call: (Validation of Route Origination using the Resource Certificate PKI and ROAs) to Informational RFC X-BeenThere: sidr@ietf.org Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 14:55:56 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Validation of Route Origination using the Resource Certificate PKI and ROAs' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-roa-validation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-roa-validation/ An IPR disclosure related to this document can be found at http://datatracker.ietf.org/ipr/1204/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1204/ _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From waehlisch@ieee.org Fri Apr 1 13:16:07 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ECA53A697D for ; Fri, 1 Apr 2011 13:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Q3nxSiglpr75 for ; Fri, 1 Apr 2011 13:16:06 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 495FC3A6964 for ; Fri, 1 Apr 2011 13:16:06 -0700 (PDT) Envelope-to: sidr@ietf.org Received: from 8-0-80-78.tmcz.cz ([78.80.0.8] helo=mw-PC) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q5kl8-000Bpn-1q; Fri, 01 Apr 2011 22:15:55 +0200 Date: Fri, 1 Apr 2011 22:17:44 +0200 From: Matthias Waehlisch To: John Scudder In-Reply-To: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> Message-ID: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: Christopher Morrow , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 20:16:07 -0000 Hi John, On Fri, 1 Apr 2011, John Scudder wrote: > > i propose that i rev the doc to say > > o the transport must provide authentication and integrity > > o the current ssh description is an example > > o other transport meeting the authentication and integrity constraints > > are welcome > > > > of course, this will leave open the mandatory-to-implement LCD issue. > > sigh. > > I think we shouldn't punt on a mandatory transport. I suggest TCP-MD5 > for practical reasons, including the open source support issue Chris > raised. > I'm confused: Do you suggest TCP-MD5 as optional or mandatory? Defining TCP-MD5 as mandatory seems a bit risky as it is obsoleted by AO. I'm not sure how the IESG would react on this. On the other hand, if there are no real implementations for RFC5925 it seems useless for RTR, as well. Thus, I would stick to SSH (or something else that is well-deployed and not obsoleted). Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From Sandra.Murphy@cobham.com Fri Apr 1 13:16:18 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 444A728C0DF for ; Fri, 1 Apr 2011 13:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.851 X-Spam-Level: X-Spam-Status: No, score=-101.851 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, NO_DNS_FOR_FROM=1.496, 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 tOkWLuJ2G9-Q for ; Fri, 1 Apr 2011 13:16:17 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A75D528C0DD for ; Fri, 1 Apr 2011 13:16:17 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p31KHvOH019597 for ; Fri, 1 Apr 2011 15:17:57 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p31KHvgI019531 for ; Fri, 1 Apr 2011 15:17:58 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([212.47.23.197]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 16:17:57 -0400 Date: Fri, 1 Apr 2011 16:18:03 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 01 Apr 2011 20:17:57.0824 (UTC) FILETIME=[E4294400:01CBF0A9] Subject: [sidr] Steve Kent's revised slides X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 20:16:18 -0000 Steve made a remark in his presentation about the last slide. Unfortunately the slide he was talking about was added to a revised slide pack that had not made it to the meeting materials site. I have now uploaded that revised slide pack to the meeting materials site, so you can see the slide Steve was talking about. IIRC, he used the word "cute" to describe that slide and I would agree. --Sandy, speaking as wg co-chair From Sandra.Murphy@cobham.com Fri Apr 1 13:22:56 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B803A697F for ; Fri, 1 Apr 2011 13:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.364 X-Spam-Level: X-Spam-Status: No, score=-101.364 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, NO_DNS_FOR_FROM=1.496, 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 uRDHoiINs4tI for ; Fri, 1 Apr 2011 13:22:53 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 0C4913A6969 for ; Fri, 1 Apr 2011 13:22:52 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p31KOVB9019662; Fri, 1 Apr 2011 15:24:31 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p31KOVRl019724; Fri, 1 Apr 2011 15:24:31 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([212.47.23.197]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 16:24:31 -0400 Date: Fri, 1 Apr 2011 16:24:37 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Andrei Robachevsky In-Reply-To: <4D95C701.9010308@gmail.com> Message-ID: References: <4D95C701.9010308@gmail.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 01 Apr 2011 20:24:31.0321 (UTC) FILETIME=[CEB42490:01CBF0AA] Cc: sidr@ietf.org Subject: Re: [sidr] suggested amendment to draft-ymbk-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 20:22:56 -0000 On Fri, 1 Apr 2011, Andrei Robachevsky wrote: > Hi, > > I propose the inclusion of the following requirement: > > 3.x A BGPsec design should not decrease the performance characteristics > of the BGP, nor have a negative impact on the overall resilience of the > routing system. Could you say how strictly you would want this requirement interpreted? For example, I would say that not even TCP-AO has NO impact on performance and resilience. Do you want the requirement to forbid TCP-AO? --Sandy, speaking as wg co-chair > > Examples that I have in mind is the convergence time or a solution that > can make the global routing system more fragile (e.g. an expired > signature blacking out a significant part of the Internet). Perhaps that > should also be covered in the deployment considerations, since this > depends partly on local policy decisions. > > Andrei > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From hannes@juniper.net Fri Apr 1 14:04:09 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55F23A698A for ; Fri, 1 Apr 2011 14:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VajxMkOnuXTA for ; Fri, 1 Apr 2011 14:04:08 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id B4D4D3A6986 for ; Fri, 1 Apr 2011 14:04:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTZY+Knu1lllVa7AfjM/pVXZLsaWsPVHl@postini.com; Fri, 01 Apr 2011 14:05:49 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Fri, 1 Apr 2011 14:03:32 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 9DBF32DDEE; Fri, 1 Apr 2011 23:05:07 +0200 (CEST) Date: Fri, 1 Apr 2011 23:05:07 +0200 From: Hannes Gredler To: Matthias Waehlisch Message-ID: <20110401210506.GA3082@juniper.net> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: John Scudder , Christopher Morrow , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 21:04:09 -0000 On Fri, Apr 01, 2011 at 10:17:44PM +0200, Matthias Waehlisch wrote: | Hi John, | | On Fri, 1 Apr 2011, John Scudder wrote: | | > > i propose that i rev the doc to say | > > o the transport must provide authentication and integrity | > > o the current ssh description is an example | > > o other transport meeting the authentication and integrity constraints | > > are welcome | > > | > > of course, this will leave open the mandatory-to-implement LCD issue. | > > sigh. | > | > I think we shouldn't punt on a mandatory transport. I suggest TCP-MD5 | > for practical reasons, including the open source support issue Chris | > raised. | > | I'm confused: Do you suggest TCP-MD5 as optional or mandatory? | | Defining TCP-MD5 as mandatory seems a bit risky as it is obsoleted by | AO. I'm not sure how the IESG would react on this. On the other hand, if | there are no real implementations for RFC5925 it seems useless for RTR, | as well. Thus, I would stick to SSH (or something else that is | well-deployed and not obsoleted). the practical problem i have with SSH is that it is pretty hard to integrate into to the async/non-blocking I/O APIs that we work with typically. openssh is select() based which does not scale terribly well if you have e.g. a couple of 100ssessions open (like it happens when doing BGP on RRs). modern, scalable I/O stacks in router OSes are exclusively based on Kqueue or Epoll. for your reference libevent has some nice description for this: see http://monkey.org/~provos/libevent/ so i'd be much more in favour of TCP-AO or even TCP-MD5 (did i mention that i am no security guy ;-)), since those are the standard tools to protect message integrity of the BGP session itself - its already onboard and does not cause much userspace / userspace transport weirdness since both for linux and BSD its implemented in the kernel. /hannes From christopher.morrow@gmail.com Fri Apr 1 14:19:25 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348E828C0F9 for ; Fri, 1 Apr 2011 14:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1Qhsqi5+UOO for ; Fri, 1 Apr 2011 14:19:24 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C352C28C0E6 for ; Fri, 1 Apr 2011 14:19:23 -0700 (PDT) Received: by wwa36 with SMTP id 36so3205766wwa.13 for ; Fri, 01 Apr 2011 14:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H+zCXG//qJUC0u62CkZ7SWbFOzcqiZgXBpi1I9uJaoM=; b=qx+ld3GmCJaLzji1Ox1Z3J4BQuXYKyGYiDVDFjl9mnW0lCMFp5H0ixOuydfrd3laIJ lA0hMU3cIEprN+PhPcys+E7RR5YFDkiqELCxnwXPlZBJl7y9fcQM0aVhehmphwmOYG0U iOaT/dUqea4MwDu61RnqRuia6wUUjr0uZyrEc= 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=agR++kCeIHVyfGK8mOc+3lQ7SqIw9mig5Atm/nPippMjFQCbbSXG73xjgsm8D+wP3s THiheWjj8OUqU6cN1KN+FVGtlfHM29Ufj4O4Y9e1ph8EPbatgdXmScnSq4bn/ElffEhS o9magIDcDJRnWZqvYCu9WL+lz7R9auDCkgKe0= MIME-Version: 1.0 Received: by 10.216.254.82 with SMTP id g60mr4137933wes.90.1301692863865; Fri, 01 Apr 2011 14:21:03 -0700 (PDT) Received: by 10.216.185.16 with HTTP; Fri, 1 Apr 2011 14:21:03 -0700 (PDT) In-Reply-To: <20110401210506.GA3082@juniper.net> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> Date: Fri, 1 Apr 2011 23:21:03 +0200 Message-ID: From: Christopher Morrow To: Hannes Gredler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: John Scudder , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 21:19:25 -0000 On Fri, Apr 1, 2011 at 11:05 PM, Hannes Gredler wrote: > On Fri, Apr 01, 2011 at 10:17:44PM +0200, Matthias Waehlisch wrote: > | Hi John, > | > | On Fri, 1 Apr 2011, John Scudder wrote: > | > | > > i propose that i rev the doc to say > | > > =A0o the transport must provide authentication and integrity > | > > =A0o the current ssh description is an example > | > > =A0o other transport meeting the authentication and integrity const= raints > | > > =A0 =A0are welcome > | > > > | > > of course, this will leave open the mandatory-to-implement LCD issu= e. > | > > sigh. > | > > | > I think we shouldn't punt on a mandatory transport. =A0I suggest TCP-= MD5 > | > for practical reasons, including the open source support issue Chris > | > raised. > | > > | =A0 I'm confused: Do you suggest TCP-MD5 as optional or mandatory? > | > | =A0 Defining TCP-MD5 as mandatory seems a bit risky as it is obsoleted = by > | AO. I'm not sure how the IESG would react on this. On the other hand, i= f > | there are no real implementations for RFC5925 it seems useless for RTR, > | as well. Thus, I would stick to SSH (or something else that is > | well-deployed and not obsoleted). > > the practical problem i have with SSH is that it is pretty hard to > integrate into to the async/non-blocking I/O APIs that we work with typic= ally. > =A0openssh is select() based which does not scale terribly well if you ha= ve > =A0e.g. a couple of 100ssessions open (like it happens when doing BGP on = RRs). So, if the configured limit of cache's was 5 would that make your arguement change in any way? (5 as an example) > =A0modern, scalable I/O stacks in router OSes are exclusively based on Kq= ueue or Epoll. > =A0for your reference libevent has some nice description for this: > =A0 =A0see http://monkey.org/~provos/libevent/ > > so i'd be much more in favour of TCP-AO or even TCP-MD5 (did i mention th= at i > am no security guy ;-)), since those are the standard tools to protect me= ssage > integrity of the BGP session itself - its already onboard and does not ca= use much > userspace / userspace transport weirdness since both for linux and BSD it= s > implemented in the kernel. > > /hannes > From hannes@juniper.net Fri Apr 1 16:38:45 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8343A69AD for ; Fri, 1 Apr 2011 16:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLypOl4aEUHB for ; Fri, 1 Apr 2011 16:38:43 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 2C35A3A69AC for ; Fri, 1 Apr 2011 16:38:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTZZiZEISJF6XLZLPe+awZzOrKiia+QS9@postini.com; Fri, 01 Apr 2011 16:40:23 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Fri, 1 Apr 2011 16:38:08 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 78CD82F38C; Sat, 2 Apr 2011 01:39:45 +0200 (CEST) Date: Sat, 2 Apr 2011 01:39:45 +0200 From: Hannes Gredler To: Christopher Morrow Message-ID: <20110401233944.GB3715@juniper.net> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: John Scudder , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 23:38:45 -0000 On Fri, Apr 01, 2011 at 11:21:03PM +0200, Christopher Morrow wrote: | On Fri, Apr 1, 2011 at 11:05 PM, Hannes Gredler wrote: | > On Fri, Apr 01, 2011 at 10:17:44PM +0200, Matthias Waehlisch wrote: | > | Hi John, | > | | > | On Fri, 1 Apr 2011, John Scudder wrote: | > | | > | > > i propose that i rev the doc to say | > | > >  o the transport must provide authentication and integrity | > | > >  o the current ssh description is an example | > | > >  o other transport meeting the authentication and integrity constraints | > | > >    are welcome | > | > > | > | > > of course, this will leave open the mandatory-to-implement LCD issue. | > | > > sigh. | > | > | > | > I think we shouldn't punt on a mandatory transport.  I suggest TCP-MD5 | > | > for practical reasons, including the open source support issue Chris | > | > raised. | > | > | > |   I'm confused: Do you suggest TCP-MD5 as optional or mandatory? | > | | > |   Defining TCP-MD5 as mandatory seems a bit risky as it is obsoleted by | > | AO. I'm not sure how the IESG would react on this. On the other hand, if | > | there are no real implementations for RFC5925 it seems useless for RTR, | > | as well. Thus, I would stick to SSH (or something else that is | > | well-deployed and not obsoleted). | > | > the practical problem i have with SSH is that it is pretty hard to | > integrate into to the async/non-blocking I/O APIs that we work with typically. | >  openssh is select() based which does not scale terribly well if you have | >  e.g. a couple of 100ssessions open (like it happens when doing BGP on RRs). | | So, if the configured limit of cache's was 5 would that make your | arguement change in any way? (5 as an example) no, as all my other "userspace" apps using TCP (in our case BGP, LDP, MSDP and rpki-cache) are all using Kqueue which makes it very simple to come up with an implementation which scale nicely under load; mixing select() with Kqueue in a daemon that has potentially 1000s of sessions would blow FD_SET to 16384, requires changing the main eventloop etc., all non-trivial changes. i mean why should i take a step backward to a select() based model just to get encryption which i do not need. - don't get me wrong SSH is great for a variety of purposes, but its certainly not the best toolkit to build a scalable transport between a client and a server. another alternative is to move the rpki-cache protocol into a sep. userspace daemon, then you are right, there is no need to be worried about the select()ism of the openssh lib, however then the performance for validating a BGP stream gets a hit by all the IPC overhead between the daemons. i remember from one of the early discussions with randy that he's very cautious about the validation overhead. | >  modern, scalable I/O stacks in router OSes are exclusively based on Kqueue or Epoll. | >  for your reference libevent has some nice description for this: | >    see http://monkey.org/~provos/libevent/ | > | > so i'd be much more in favour of TCP-AO or even TCP-MD5 (did i mention that i | > am no security guy ;-)), since those are the standard tools to protect message | > integrity of the BGP session itself - its already onboard and does not cause much | > userspace / userspace transport weirdness since both for linux and BSD its | > implemented in the kernel. | > | > /hannes | > From kent@bbn.com Sat Apr 2 02:08:28 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4CF3A6A6B for ; Sat, 2 Apr 2011 02:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOYB7KCNIdzg for ; Sat, 2 Apr 2011 02:08:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 03B233A6A65 for ; Sat, 2 Apr 2011 02:08:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:45282 helo=[172.30.28.142]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5wqM-0006Zh-Fd; Sat, 02 Apr 2011 05:10:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> Date: Sat, 2 Apr 2011 04:54:50 -0400 To: John Scudder From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Christopher Morrow , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 09:08:28 -0000 At 6:32 AM -0700 4/1/11, John Scudder wrote: >On Apr 1, 2011, at 1:22 PM, Randy Bush wrote: >> i propose that i rev the doc to say >> o the transport must provide authentication and integrity >> o the current ssh description is an example >> o other transport meeting the authentication and integrity constraints >> are welcome >> >> of course, this will leave open the mandatory-to-implement LCD issue. >> sigh. > >I think we shouldn't punt on a mandatory transport. I suggest >TCP-MD5 for practical reasons, including the open source support >issue Chris raised. > >--John I expect TCP-MD5 to be deprecated (soon?), since we have already deprecated MD5. I don't think the IESG would approve of a reference to that RFC. Steve From jgs@juniper.net Sat Apr 2 02:12:04 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7383A6A65 for ; Sat, 2 Apr 2011 02:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 xI8D3WvaySkq for ; Sat, 2 Apr 2011 02:12:04 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id C833C3A69EE for ; Sat, 2 Apr 2011 02:12:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTZboxnae5g7Y/7RxCq30Amf1HoSZjMmj@postini.com; Sat, 02 Apr 2011 02:13:45 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Sat, 2 Apr 2011 02:11:14 -0700 From: John Scudder To: Stephen Kent Date: Sat, 2 Apr 2011 02:12:47 -0700 Thread-Topic: [sidr] WGLC draft-sidr-rpki-rtr - take 2? Thread-Index: AcvxFenv9M5se/K9RgSoBlOzoH18rQ== Message-ID: <34B69BAE-E351-4724-B377-6574766EE8D3@juniper.net> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Christopher Morrow , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 09:12:04 -0000 On Apr 2, 2011, at 10:54 AM, Stephen Kent wrote: > At 6:32 AM -0700 4/1/11, John Scudder wrote: >> On Apr 1, 2011, at 1:22 PM, Randy Bush wrote: >>> i propose that i rev the doc to say >>> o the transport must provide authentication and integrity >>> o the current ssh description is an example >>> o other transport meeting the authentication and integrity constraints >>> are welcome >>>=20 >>> of course, this will leave open the mandatory-to-implement LCD issue. >>> sigh. >>=20 >> I think we shouldn't punt on a mandatory transport. I suggest TCP-MD5 f= or practical reasons, including the open source support issue Chris raised. >>=20 >> --John >=20 > I expect TCP-MD5 to be deprecated (soon?), since we have already deprecat= ed MD5. I don't think the IESG would approve of a reference to that RFC. Well it was worth a try. I think the next-best option is TCP-AO. --John= From waehlisch@ieee.org Sat Apr 2 02:20:42 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36A523A6784 for ; Sat, 2 Apr 2011 02:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 M-lyDA7rLQKA for ; Sat, 2 Apr 2011 02:20:41 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 007C43A65A5 for ; Sat, 2 Apr 2011 02:20:40 -0700 (PDT) Envelope-to: sidr@ietf.org Received: from 8-0-80-78.tmcz.cz ([78.80.0.8] helo=mw-PC.meeting.ietf.org) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q5x0Q-000O8y-Ei; Sat, 02 Apr 2011 11:20:30 +0200 Date: Sat, 2 Apr 2011 11:22:18 +0200 From: Matthias Waehlisch To: Hannes Gredler In-Reply-To: <20110401210506.GA3082@juniper.net> Message-ID: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: John Scudder , Christopher Morrow , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 09:20:42 -0000 Hi Hannes, On Fri, 1 Apr 2011, Hannes Gredler wrote: > so i'd be much more in favour of TCP-AO or even TCP-MD5 (did i mention > that i am no security guy ;-)), since those are the standard tools to > protect message integrity of the BGP session itself - its already > onboard and does not cause much userspace / userspace transport > weirdness since both for linux and BSD its implemented in the kernel. > could you give a reference to both, Linux and BSD, TCP-AO implementations? Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From jgs@juniper.net Sat Apr 2 02:41:37 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1999D3A6A6C for ; Sat, 2 Apr 2011 02:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 z8ONU6mEaB-q for ; Sat, 2 Apr 2011 02:41:36 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 6FA5D3A6A6A for ; Sat, 2 Apr 2011 02:41:36 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTZbvs3VzYvcv3r0lQ+gvGYxifZSZYn+g@postini.com; Sat, 02 Apr 2011 02:43:17 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Sat, 2 Apr 2011 02:30:10 -0700 From: John Scudder To: Matthias Waehlisch Date: Sat, 2 Apr 2011 02:31:45 -0700 Thread-Topic: [sidr] WGLC draft-sidr-rpki-rtr - take 2? Thread-Index: AcvxGI/rrv04QsAGTYS03UCwKCKL+A== Message-ID: <95ED0F08-3F8E-44D3-9BD5-D0BB8604F854@juniper.net> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Christopher Morrow , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 09:41:37 -0000 On Apr 2, 2011, at 11:22 AM, Matthias Waehlisch wrote: > could you give a reference to both, Linux and BSD, TCP-AO=20 > implementations? I can't (possibly due only to my own ignorance) but I'll observe that since= as both you and Steven Kent have observed TCP-MD5 is being deprecated, bot= h Linux and BSD will need to add TCP-AO anyway. =20 --John= From danny@tcb.net Sat Apr 2 06:02:53 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A3A3A67F0 for ; Sat, 2 Apr 2011 06:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.193 X-Spam-Level: X-Spam-Status: No, score=-110.193 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 QV8SbfTdmSR2 for ; Sat, 2 Apr 2011 06:02:53 -0700 (PDT) Received: from farnsworth.verisignlabs.com (farnsworth.verisignlabs.com [72.13.58.64]) by core3.amsl.com (Postfix) with ESMTP id 06D103A67EC for ; Sat, 2 Apr 2011 06:02:53 -0700 (PDT) Received: from monsoon.verisignlabs.com (h87.s239.verisign.com [216.168.239.87]) by farnsworth.verisignlabs.com (Postfix) with ESMTP id 22C7CA539; Sat, 2 Apr 2011 13:04:34 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (dul1dmcphers-m2.vcorp.ad.vrsn.com [10.100.0.40]) by monsoon.verisignlabs.com (Postfix) with ESMTP id CFEE124251E; Sat, 2 Apr 2011 09:04:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <4D95C701.9010308@gmail.com> Date: Sat, 2 Apr 2011 09:04:33 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4D95C701.9010308@gmail.com> To: Andrei Robachevsky X-Mailer: Apple Mail (2.1082) Cc: sidr@ietf.org Subject: Re: [sidr] suggested amendment to draft-ymbk-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 13:02:54 -0000 On Apr 1, 2011, at 8:37 AM, Andrei Robachevsky wrote: > Hi, > > I propose the inclusion of the following requirement: > > 3.x A BGPsec design should not decrease the performance characteristics > of the BGP, nor have a negative impact on the overall resilience of the > routing system. > > Examples that I have in mind is the convergence time or a solution that > can make the global routing system more fragile (e.g. an expired > signature blacking out a significant part of the Internet). Perhaps that > should also be covered in the deployment considerations, since this > depends partly on local policy decisions. As much as I'd love to support this, ultimately, any time you add integrity mechanisms to an information system you simply introduce more ways to fail, no? OTOH, it's important to be aware that new externalities and/or dependencies are being added, and we should aim not to step all the way back to RIPv1 scaling properties - brushing aside all that's been learned over the past several decades. -danny From russ@cisco.com Sat Apr 2 10:22:49 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2A93A686C for ; Sat, 2 Apr 2011 10:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.395 X-Spam-Level: X-Spam-Status: No, score=-10.395 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 eNJ0sovWx7ta for ; Sat, 2 Apr 2011 10:22:48 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 675093A6867 for ; Sat, 2 Apr 2011 10:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1114; q=dns/txt; s=iport; t=1301765069; x=1302974669; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=LAsBtvPEYzN6J9DPv0aaDH90qyGKHgWxtdElnRYSstI=; b=gmx2xjJf5wid+co2UzdU/CPVNGjz//mISCjCdkmoCcFQf1Y1gMt2T/OJ 4nHZ1hOWPhg3WSb1h8k4NjpzkANyoWebqKL/7yX7i16Q2Yqt13rNPs5wG nECo0ljyGoeJVvB/SoLiZ912f2PgyD8foGQWF3a1MzriWoUesSsrd9VM8 A=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAORal02tJV2c/2dsb2JhbAClY3eIeZpym1iFawSNI4Nb X-IronPort-AV: E=Sophos;i="4.63,288,1299456000"; d="asc'?scan'208";a="282028913" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2011 17:24:29 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p32HOSGF021998; Sat, 2 Apr 2011 17:24:29 GMT Message-ID: <4D975BC0.9080608@cisco.com> Date: Sat, 02 Apr 2011 13:24:16 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Doug Montgomery References: <4D95C701.9010308@gmail.com> <4D95D4B6.9050704@gmail.com> In-Reply-To: <4D95D4B6.9050704@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5992EC3DE2163EED1CCB39EC" Cc: sidr@ietf.org Subject: Re: [sidr] suggested amendment to draft-ymbk-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 17:22:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5992EC3DE2163EED1CCB39EC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > As it stands now, BGPSEC is opt-in. So it seems that clearly > documenting these issues is more operative than make absolute > requirements about them. Does this mean BGPSEC is not designated as a standards track document? how can a security system actually work if it's "opt in?" It sounds like this is an area that needs some discussion around it. :-) Russ --------------enig5992EC3DE2163EED1CCB39EC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2XW8IACgkQER27sUhU9OQQVgCdF9T9kmn3Rqd4fwrF1y7URri+ jycAn2Jq45kGYlnee9+nftcnnuIiYmt+ =kouy -----END PGP SIGNATURE----- --------------enig5992EC3DE2163EED1CCB39EC-- From russ@cisco.com Sat Apr 2 10:25:24 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A853A686C for ; Sat, 2 Apr 2011 10:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.505 X-Spam-Level: X-Spam-Status: No, score=-10.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 zgXZdw6ScVUa for ; Sat, 2 Apr 2011 10:25:22 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 805E23A6867 for ; Sat, 2 Apr 2011 10:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1522; q=dns/txt; s=iport; t=1301765223; x=1302974823; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=RmLoDrdb5TLCi7yVLMpc9ivTilpABy8sVNV+nK14V2w=; b=jL7vTWaZcYZEnJHw5X//8jJYTXJNIch6A7w6nQfLdLOkojvNSBB0dSEm E8e7szebjkjso7loSAhJGYHiKx75faXC60nCU+49ZEdFFfZyUNzR/KJZN /RoE2H5d/FMitCSMp9v4hZiB2HvQq3+DzHteiUce5g9Txxuz1d1CNNK2K w=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFdbl02tJV2Y/2dsb2JhbAClY3eIeZpqm1iFawSNI4Nb X-IronPort-AV: E=Sophos;i="4.63,288,1299456000"; d="asc'?scan'208";a="329552778" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 02 Apr 2011 17:27:03 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p32HR3VW010798; Sat, 2 Apr 2011 17:27:03 GMT Message-ID: <4D975C5D.7080808@cisco.com> Date: Sat, 02 Apr 2011 13:26:53 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jeffrey Haas References: <20110401131142.GA15519@slice> In-Reply-To: <20110401131142.GA15519@slice> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8E67CC3BC499FCA0FFED33A6" Cc: sidr@ietf.org Subject: Re: [sidr] IETF 80 - suggestions related to expiry time and BGP implementation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 17:25:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8E67CC3BC499FCA0FFED33A6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > 1. Text should be added to strongly recommend that when a route that is= > about to expire is having an update of the expiration advertised that > receiving peers should treat the reception of an update with no other > changes to the reachability than the expiration time and signatures as = a > refresh of the existing route. Implementations supporting temporal tim= e > breaking in path selection should *not* treat the refresh as a new upda= te. I would think the problem here is that the BGP implementation must: 1. Know not to know run bestpath on such a path change. 2. Know to send a new update, although the bestpath hasn't changed. It would be useful to indicate the portions of the BGP RFCs that must be changed in order to support this. :-) Russ --------------enig8E67CC3BC499FCA0FFED33A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2XXF0ACgkQER27sUhU9ORD+gCdGHME0vBtExQ/DnSfkg29yuLC vyQAnAv1pmUtcjobaMC+u4Wd1dpzHyFQ =2H8P -----END PGP SIGNATURE----- --------------enig8E67CC3BC499FCA0FFED33A6-- From randy@psg.com Sat Apr 2 17:33:31 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D5C3A68FA for ; Sat, 2 Apr 2011 17:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NOGabWdsSTy for ; Sat, 2 Apr 2011 17:33:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id F18483A68F4 for ; Sat, 2 Apr 2011 17:33:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-2643.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6BGN-0000UF-4u; Sun, 03 Apr 2011 00:33:55 +0000 Date: Sat, 02 Apr 2011 17:33:59 -0700 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Steven M Bellovin , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 00:33:32 -0000 > I expect TCP-MD5 to be deprecated (soon?), since we have already > deprecated MD5. I don't think the IESG would approve of a reference > to that RFC. as opposed to second guessing the iesg, prehaps asking if mmd5+hmac would be reasonable as mandatory to implement. randy From randy@psg.com Sun Apr 3 06:38:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10AF53A6801 for ; Sun, 3 Apr 2011 06:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhmLzZF01skE for ; Sun, 3 Apr 2011 06:38:02 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 9C0603A67EC for ; Sun, 3 Apr 2011 06:38:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-2643.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6NVb-0002pL-9R; Sun, 03 Apr 2011 13:38:27 +0000 Date: Sun, 03 Apr 2011 06:38:26 -0700 Message-ID: From: Randy Bush To: John Scudder In-Reply-To: <34B69BAE-E351-4724-B377-6574766EE8D3@juniper.net> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <34B69BAE-E351-4724-B377-6574766EE8D3@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 13:38:03 -0000 > I think the next-best option is TCP-AO. this suffers from a lack of implementations on server platforms randy From christopher.morrow@gmail.com Sun Apr 3 08:44:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66E43A6835 for ; Sun, 3 Apr 2011 08:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.461 X-Spam-Level: X-Spam-Status: No, score=-103.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1USyH7dRmGfw for ; Sun, 3 Apr 2011 08:44:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id D19593A6823 for ; Sun, 3 Apr 2011 08:44:02 -0700 (PDT) Received: by wyb29 with SMTP id 29so4596390wyb.31 for ; Sun, 03 Apr 2011 08:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UEBeTL8xykglzKK+wQEEjho3Qh1R5AaAV7dPR+dT/Oo=; b=tHSj0f2ds8Nzr5eC9xQqo0BpxDxgy+bAwEj26cpyOK1douIJ/YzyqzauG+EzY2+kcd SXjgooXLopLIl79qM0UkvCovm+bw7fTUfkReviZpyW95KwdMXZj+7Sf1rg9yLxVjSVTm XM0gsERgUz3iwpYfyPiRunjLAB7j7JY5IbgI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=D/KSSY3Cdmu7sWkGEIGGTEVDgpIMf8Svcl/HbeckDy+kCbaX27fYB8zOBYL6OFiEaE Y7WfN68uLEg7RJUqr2As7PGRmuTaK/K2mRdoYuOy8AnDRpzXlObLZMrufbHqXtp5rsXR 0+kbTZ9vxu4AF42m3hBvvOZuhyYqzc/t1esKE= MIME-Version: 1.0 Received: by 10.216.244.6 with SMTP id l6mr2868788wer.60.1301845544097; Sun, 03 Apr 2011 08:45:44 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.185.16 with HTTP; Sun, 3 Apr 2011 08:45:43 -0700 (PDT) In-Reply-To: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <34B69BAE-E351-4724-B377-6574766EE8D3@juniper.net> Date: Sun, 3 Apr 2011 17:45:43 +0200 X-Google-Sender-Auth: _qFxKlbfaxhbTNo3h_MnZ1fr32c Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: John Scudder , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 15:44:03 -0000 On Sun, Apr 3, 2011 at 3:38 PM, Randy Bush wrote: >> I think the next-best option is TCP-AO. > > this suffers from a lack of implementations on server platforms so ... if we need this on server platforms what's the 'cost' (free since they are both free-unixes! ) people-wise? I think I hear ~6mon for the linux side, though I'm teasing out the details a bit still. -Chris From Wesley.E.George@sprint.com Sun Apr 3 17:10:11 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5CE28B56A for ; Sun, 3 Apr 2011 17:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.553 X-Spam-Level: X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[AWL=1.046, 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 rp3dyFp7LmUe for ; Sun, 3 Apr 2011 17:10:10 -0700 (PDT) Received: from VA3EHSOBE007.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id 118AA3A68C0 for ; Sun, 3 Apr 2011 17:10:10 -0700 (PDT) Received: from mail21-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.8; Mon, 4 Apr 2011 00:11:51 +0000 Received: from mail21-va3 (localhost.localdomain [127.0.0.1]) by mail21-va3-R.bigfish.com (Postfix) with ESMTP id E2D644A8260; Mon, 4 Apr 2011 00:11:51 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371P542N4015Lzz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail21-va3 (localhost.localdomain [127.0.0.1]) by mail21-va3 (MessageSwitch) id 130187589723178_16027; Mon, 4 Apr 2011 00:11:37 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.246]) by mail21-va3.bigfish.com (Postfix) with ESMTP id CBCA11588085; Mon, 4 Apr 2011 00:11:02 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 4 Apr 2011 00:10:58 +0000 Received: from PDAWEH05.ad.sprint.com (PDAWEH05.corp.sprint.com [144.226.110.92]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p340Ak40026847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Apr 2011 19:10:47 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH05.ad.sprint.com ([2002:90e2:6e5c::90e2:6e5c]) with mapi id 14.01.0270.001; Sun, 3 Apr 2011 19:10:46 -0500 From: "George, Wes E [NTK]" To: Jeffrey Haas , "sidr@ietf.org" Thread-Topic: [sidr] IETF 80 - suggestions related to expiry time and BGP implementation Thread-Index: AQHL8G5dMLsCjzJMGE2PLK7ViLdkIpRKvOZg Date: Mon, 4 Apr 2011 00:10:44 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6ACDF@PLSWM12A.ad.sprint.com> References: <20110401131142.GA15519@slice> In-Reply-To: <20110401131142.GA15519@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.75] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0162_01CBF12F.60D686E0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: Re: [sidr] IETF 80 - suggestions related to expiry time and BGP implementation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 00:10:11 -0000 ------=_NextPart_000_0162_01CBF12F.60D686E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Friday, April 01, 2011 9:12 AM To: sidr@ietf.org Subject: [sidr] IETF 80 - suggestions related to expiry time and BGP implementation 2. Short expiry times are an attack on the routing system, especially boxes with slow signature processors. Routes that will expire "soon" should be refreshed with enough time so that receiving peers can take their own sweet time to validate that a new valid path has been received in spare cycles. [WEG] Along those same lines - I think we need a global minimum value for beacons to reduce the exposure to this DoS attack (on the validating router) vector. We already have scaling issues when too many eBGP peers set their BGP timers too aggressively on the same box, and that is at least locally controllable by enforcing a minimum in the negotiated session. There's no negotiation happening here, and therefore no way to protect those routers, short of ignoring updates, which generates stale routes and probably churn (depending on the policy). In fact, this starts looking a lot like the Route Flap Dampening problem we're trying to solve elsewhere in IETF - a very small amount of the prefixes might be responsible for an overwhelming majority of the updates to the detriment of the routing system's performance. Even if it's just a refresh, there's a non-trivial impact if too many people start being overly paranoid about their expiry times. But by the same token, being too conservative with the expiry means that there is a longer period of exposure where a replay would be effective, and the value of implementing the overhead at all starts becoming questionable. How long is too long for a replay attack to go unnoticed? I'd bet that a lot of the folks worried about this would answer in minutes, while those concerned primarily with the hardware in their routers would answer in hours... This is an area where any info we have about the prevalence of replay attacks and their characteristics would be really helpful in determining how much risk we are preventing by addressing this specific attack vector vs how much overhead we're generating with this expiry machinery. Thanks, Wes George ------=_NextPart_000_0162_01CBF12F.60D686E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDITCCAx0CAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB8DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0MDIxNjEzMzBaMCMGCSqGSIb3DQEJBDEWBBSqOEso+i60 zZUh9tzwUxzyPoTO5DBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjCBlwYJKwYB BAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJp bnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNl IElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJEAILMYGJoIGGMHgx EzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/Is ZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRo b3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYCZoCtVsNAYYctWUA0Nd+zXnjum6Y2l CBdrK5AvVi5jqEv1v61bO3lDPxEISYkda7z5bIHhvIqwAJBYz+hbqI4/PIGdEBl7ga64YZoFnX9W QtJN6HBGBlbPeCr2VhGmeMGW/zETbmQxXnv3aAqWM/GzAsgacwDvlqhWPoixseomWQAAAAAAAA== ------=_NextPart_000_0162_01CBF12F.60D686E0-- From Wesley.E.George@sprint.com Sun Apr 3 17:16:15 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9703A6825 for ; Sun, 3 Apr 2011 17:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.628 X-Spam-Level: X-Spam-Status: No, score=-5.628 tagged_above=-999 required=5 tests=[AWL=0.971, 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 rtEnZ5sIQrkU for ; Sun, 3 Apr 2011 17:16:14 -0700 (PDT) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by core3.amsl.com (Postfix) with ESMTP id A0A423A68C0 for ; Sun, 3 Apr 2011 17:16:14 -0700 (PDT) Received: from mail122-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.8; Mon, 4 Apr 2011 00:17:56 +0000 Received: from mail122-tx2 (localhost.localdomain [127.0.0.1]) by mail122-tx2-R.bigfish.com (Postfix) with ESMTP id 21B201B20102 for ; Mon, 4 Apr 2011 00:17:56 +0000 (UTC) X-SpamScore: -9 X-BigFish: VS-9(zz1418M4015Lzz1202hzzz2fh2a8h668h839h34h64h) X-Spam-TCS-SCL: 3:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI Received: from mail122-tx2 (localhost.localdomain [127.0.0.1]) by mail122-tx2 (MessageSwitch) id 1301876275859019_4791; Mon, 4 Apr 2011 00:17:55 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.254]) by mail122-tx2.bigfish.com (Postfix) with ESMTP id C52B7A48051 for ; Mon, 4 Apr 2011 00:17:55 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 4 Apr 2011 00:17:55 +0000 Received: from PDAWEH01.ad.sprint.com (PDAWEH01.corp.sprint.com [144.226.110.69]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p340Hsh4009007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 3 Apr 2011 19:17:54 -0500 Received: from PDAWEH04.ad.sprint.com (144.226.111.59) by PDAWEH01.ad.sprint.com (144.226.110.69) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 3 Apr 2011 19:17:54 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH04.ad.sprint.com ([2002:90e2:6f3b::90e2:6f3b]) with mapi id 14.01.0270.001; Sun, 3 Apr 2011 19:17:54 -0500 From: "George, Wes E [NTK]" To: "sidr@ietf.org" Thread-Topic: BCP for implementing RPKI? Thread-Index: AcvyXbuB9it8+ktmTaaJ/hQha6BlcA== Date: Mon, 4 Apr 2011 00:17:53 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6AE16@PLSWM12A.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.75] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0031_01CBF23C.36099BB0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: [sidr] BCP for implementing RPKI? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 00:16:15 -0000 ------=_NextPart_000_0031_01CBF23C.36099BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I had a conversation with a couple of folks while at IETF that they thought I should bring to the list for discussion. While we have an operational considerations document that covers origin validation, it focuses mainly on policy and implementation details of the validation machinery. We don't have anything that covers the back-end of implementing a proper RPKI (from the cache upward, rather than downward towards the router). Put another way, a lot of the folks involved in this protocol's design and implementation are already intimately familiar with how to manage things like ROAs to ensure that the underlying trust of the system is not compromised. I (and I assume other operators and likely the RIR staff) on the other hand. not so much. Keep in mind that while we might consult with our security folks on implementation details, that doesn't necessarily mean that we'll do it right, since the level of knowledge of the considerations here by the security folks may be limited. Since ultimately origin validation's trust level is only as good as the trust level associated with management of the validation keys, I'm quite certain that additional rigor is necessary in both the way that RIRs manage their POC records and authority to request, invalidate, and reissue keys, as well as how ISPs do the same for their downstream customers, especially since these are likely to be managed through some form of automated back-office system or customer portal. So I think that there is a need for a document that covers things like identity and authority management, minimum levels of security for key management, etc. Basically, if you had to explain to someone how to ensure that the ROAs that are being delegated are: 1) Delegated to the right person (right company, and person authorized to make the changes within the company) 2) Have a reasonable assumption that they will not be compromised once delegated (proper key management) 3) Methods for managing breaches, either due to failures in #1 (disgruntled/former employee) or failures in #2 How would you do it? Are there existing documents we can use as a baseline and just fill in some of the specific details in the form of a few different use cases, such as RIR to primary resource holder, resource holder to delegate, etc? An example to illustrate the reason for this - we have a subsidiary that we bought that had their own address space. Somewhere along the way, a former employee changed the whois and POC info in ARIN's database to point to a new company, and said new company started threatening to announce "their" address space that we were squatting on. Obviously a quick contact to ARIN sorted this out, but under less amiable circumstances, they could have invalidated our existing ROA, issued their own, and created a serious problem for us. While the solution is primarily that companies need to stay on top of their POC records now, we need to make that clear as a part of the documentation that we're providing on how to implement this system and we need to try to give ideas on how best to improve the level of trust. I'm happy to help play the part of RPKI n00b to ensure that a draft written to cover this answers the right questions, but for the same reason, I cannot help much with actually writing it, and am hoping that there are folks interested in picking up this work. Thanks, Wes George ------=_NextPart_000_0031_01CBF23C.36099BB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDITCCAx0CAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB8DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0MDQwMDE3NTJaMCMGCSqGSIb3DQEJBDEWBBRMt5q7Aeyf WMov3WLguxz1n+KSEzBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjCBlwYJKwYB BAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJp bnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNl IElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJEAILMYGJoIGGMHgx EzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/Is ZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRo b3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYBPD5NgT7ck4hq6krLPBZ3CPFEPgPtz SHeXvXefV6fErhckRrwO5YPapbCkBJbsiPieFc644X89JjkUB3S+Tb4Yrkc1iO7DDzV75euGlAyl 1AGjUv5JsaEnF3eHoHjoRWUTyPnu0+LkHeYu190MG5/Yoyot2GY/+Gs6V6OtjsHBHAAAAAAAAA== ------=_NextPart_000_0031_01CBF23C.36099BB0-- From Wesley.E.George@sprint.com Sun Apr 3 17:16:29 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2DE28C0CE for ; Sun, 3 Apr 2011 17:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.192 X-Spam-Level: X-Spam-Status: No, score=-4.192 tagged_above=-999 required=5 tests=[AWL=-0.593, 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 0OjpMLpT-VNX for ; Sun, 3 Apr 2011 17:16:27 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1outboundpool.messaging.microsoft.com [216.32.181.185]) by core3.amsl.com (Postfix) with ESMTP id 9F4DB3A6889 for ; Sun, 3 Apr 2011 17:16:27 -0700 (PDT) Received: from mail172-ch1-R.bigfish.com (216.32.181.173) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.8; Mon, 4 Apr 2011 00:18:09 +0000 Received: from mail172-ch1 (localhost.localdomain [127.0.0.1]) by mail172-ch1-R.bigfish.com (Postfix) with ESMTP id EFCB5938249 for ; Mon, 4 Apr 2011 00:18:08 +0000 (UTC) X-SpamScore: -9 X-BigFish: VS-9(zz1418M4015Lzz1202hzz8275chz2fh2a8h668h839h34h) X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail172-ch1 (localhost.localdomain [127.0.0.1]) by mail172-ch1 (MessageSwitch) id 1301876288681170_10116; Mon, 4 Apr 2011 00:18:08 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail172-ch1.bigfish.com (Postfix) with ESMTP id A2DF8AA004F for ; Mon, 4 Apr 2011 00:18:08 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 4 Apr 2011 00:18:08 +0000 Received: from PDAWEH01.ad.sprint.com (PDAWEH01.corp.sprint.com [144.226.110.69]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p340I3ED030810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 3 Apr 2011 19:18:07 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH01.ad.sprint.com ([2002:90e2:6e45::90e2:6e45]) with mapi id 14.01.0270.001; Sun, 3 Apr 2011 19:18:05 -0500 From: "George, Wes E [NTK]" To: "sidr@ietf.org" Thread-Topic: comments on BGPsec drafts Thread-Index: AcvyXcE0ghYLxcQBRUKqBiJjrh2AuA== Date: Mon, 4 Apr 2011 00:18:03 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6AE1F@PLSWM12A.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.75] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003B_01CBF23C.3C46E5F0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: [sidr] comments on BGPsec drafts X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 00:16:29 -0000 ------=_NextPart_000_003B_01CBF23C.3C46E5F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Providing some comments on the drafts as a whole. BGPsec Protocol spec - Section 4 requires that each update contain only one NLRI. While you explained in the presentation why this is, it is not adequately explained in the draft. Since this is a significant change, and is currently based on a technical limitation, please explain it here. As stated at the mic, please consider a second (or third) state of validation - expired. It may be that different policy should be applied in these cases vs. known invalid. BGP Sec Overview - 3.2 talks about the recursive nature of the validation. It is probably worth noting that this is going to have at least some impact on convergence times - long AS paths may take longer to validate than shorter ones, for example, where this isn't really variable today. This may be an issue depending on how the validation is implemented and the order the updates come in, especially if you parallelize the processing of updates (that is, the router is still chewing on validation of one update while the next one is being processed on a different core) - it can cause route churn as one route is preferred and then discarded to pick up another, etc. This churn is a known issue on initial convergence, but there is often machinery in routers to allow for prioritization of certain prefixes, certain prefix lengths, etc to limit its effects. I am mainly saying that you should consider the implications of this. Worth discussing if it's even an option to consider parallelization of validation *within* a given update (feed one AS signature to each core so that you're processing multiples at once, for example) - I know we're not at the design optimization phase yet, but if there's a technical reason why this isn't possible or isn't recommended, might be worth making it clear. 4.3 - use case : while I understand we're talking about dumping AS-sets, I think that replace-AS to eliminate private AS is a valid use case that has to be supported by this implementation. It may be that we have to assume that the AS that is serving as the replacement is also serving as the originator and signing on behalf of the upstream private ASN, but that should be explicitly documented if that's what we're aiming for. Operational considerations - As I and others stated at the mic, while we're not expecting formal estimates of something that is in a pre-optimization stage of design, rough orders of magnitude in terms of the impact to processing and convergence time, CPU, and RIB memory are all things that would be extremely helpful in evaluating this. Assuming a certain crypto algorithm, what would the expected size of a single update be when compared with today, for example? Since we're not packing, the research that has been done to show that packing isn't that important should be directly referenced here, etc. We know that the design team considered scale and convergence as a top priority, but that's not well-covered in the current drafts. Security considerations - the same issues as origin validation has with existing routing policy (local pref, for example) being able to create a situation where an invalid route is preferred over a valid one should be either discussed here or referenced from the other document. Thanks, Wes _________________________________ Wesley George Sprint Core Network Engineering - IP O: 703-592-4847 M:703-864-4902 http://www.sprint.net Please note new office phone# This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. ------=_NextPart_000_003B_01CBF23C.3C46E5F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDITCCAx0CAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB8DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0MDQwMDE4MDNaMCMGCSqGSIb3DQEJBDEWBBRdQhT2X8x9 D1BYUhIQh1UJPmG+3DBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjCBlwYJKwYB BAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJp bnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNl IElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJEAILMYGJoIGGMHgx EzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/Is ZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRo b3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYCd3bKe3LpmIEyyDuiQ/t61P6BSStE8 JcSWdElctT7xKeoCTBoPcl/Nmg8uJkjKH4Ltc7FbmG66BQ3DaHazG0ZZXpWBgBRHpCZQ4mTkIIv4 /ShLVW3lfnyeYgy9yyD982Wr6GmUDHjZXOPK496vqi2lrLZKCsh8PMY2zN7wXUEPXQAAAAAAAA== ------=_NextPart_000_003B_01CBF23C.3C46E5F0-- From carlosm3011@gmail.com Sun Apr 3 17:46:54 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD803A68E7 for ; Sun, 3 Apr 2011 17:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 HPV-BBxgoY3S for ; Sun, 3 Apr 2011 17:46:53 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id F2EDD3A68CE for ; Sun, 3 Apr 2011 17:46:52 -0700 (PDT) Received: by gyf3 with SMTP id 3so2340705gyf.31 for ; Sun, 03 Apr 2011 17:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xJAN0V1kZrpuZIbXVTecv4crSDK9d5sqXrvKcFSrwK8=; b=FULzNnEPtzfX9+RdG7Ue+MEh759tkggh4hS9knh0EeoBWappJD2x0BendwbsH8uf+D iII/Jvnrx2GYXhbCC+gRqeRrrWiFVu9jyr9GJn4kAbGhZRqVQrObiz/JxW8PDCmKuI/b qtcDkC4srhAIAD3hiBzQWZsB7veZ3ozmVFjT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=dEjgOg5d49VZP80rx7CqnZB4mqArqweMad02m7LhH/FYod3VZ1c/F+EQFXBgGQeBmV DQHgOkQe0skM7zL9e0f7GsgavcOnDW1Jp3r9s+L4QC754pRDzB8JGqbhbkkOloEnu4NS bTI2JgLV5nrRueTaI4YIEEjbLgW2HK3sixaYs= MIME-Version: 1.0 Received: by 10.90.9.34 with SMTP id 34mr5609514agi.153.1301878113071; Sun, 03 Apr 2011 17:48:33 -0700 (PDT) Received: by 10.90.56.12 with HTTP; Sun, 3 Apr 2011 17:48:32 -0700 (PDT) In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6AE16@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6AE16@PLSWM12A.ad.sprint.com> Date: Sun, 3 Apr 2011 21:48:32 -0300 Message-ID: From: Carlos Martinez-Cagnazzo To: "George, Wes E [NTK]" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org" Subject: Re: [sidr] BCP for implementing RPKI? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 00:46:54 -0000 I see your point, although it seems to me that the underlying problem might be more general than RPKI. The RIRs have also been operating business CAs for some time and I dare say they (we?) are up to the task of correctly managing cryptographic material This does not mean breaches can=B4t occur, but rather that I believe they will be handled appropriately. That said, I believe documenting best practices is always a good idea. Do you think a new, different document is needed or that practices you want documented can be included in the CPS documents ? regards Carlos On Sun, Apr 3, 2011 at 9:17 PM, George, Wes E [NTK] wrote: > I had a conversation with a couple of folks while at IETF that they thoug= ht I should bring to the list for discussion. > > While we have an operational considerations document that covers origin v= alidation, it focuses mainly on policy and implementation > details of the validation machinery. We don't have anything that covers t= he back-end of implementing a proper RPKI (from the cache > upward, rather than downward towards the router). > > Put another way, a lot of the folks involved in this protocol's design an= d implementation are already intimately familiar with how > to manage things like ROAs to ensure that the underlying trust of the sys= tem is not compromised. > I (and I assume other operators and likely the RIR staff) on the other ha= nd. not so much. Keep in mind that while we might consult > with our security folks on implementation details, that doesn't necessari= ly mean that we'll do it right, since the level of > knowledge of the considerations here by the security folks may be limited= . Since ultimately origin validation's trust level is only > as good as the trust level associated with management of the validation k= eys, I'm quite certain that additional rigor is necessary > in both the way that RIRs manage their POC records and authority to reque= st, invalidate, and reissue keys, as well as how ISPs do > the same for their downstream customers, especially since these are likel= y to be managed through some form of automated back-office > system or customer portal. > > So I think that there is a need for a document that covers things like id= entity and authority management, minimum levels of security > for key management, etc. > > Basically, if you had to explain to someone how to ensure that the ROAs t= hat are being delegated are: > 1) =A0 =A0 =A0Delegated to the right person (right company, and person au= thorized to make the changes within the company) > 2) =A0 =A0 =A0Have a reasonable assumption that they will not be compromi= sed once delegated (proper key management) > 3) =A0 =A0 =A0Methods for managing breaches, either due to failures in #1= (disgruntled/former employee) or failures in #2 > How would you do it? Are there existing documents we can use as a baselin= e and just fill in some of the specific details in the form > of a few different use cases, such as RIR to primary resource holder, res= ource holder to delegate, etc? > An example to illustrate the reason for this - we have a subsidiary that = we bought that had their own address space. Somewhere along > the way, a former employee changed the whois and POC info in ARIN's datab= ase to point to a new company, and said new company started > threatening to announce "their" address space that we were squatting on. = Obviously a quick contact to ARIN sorted this out, but > under less amiable circumstances, they could have invalidated our existin= g ROA, issued their own, and created a serious problem for > us. While the solution is primarily that companies need to stay on top of= their POC records now, we need to make that clear as a > part of the documentation that we're providing on how to implement this s= ystem and we need to try to give ideas on how best to > improve the level of trust. > > I'm happy to help play the part of RPKI n00b to ensure that a draft writt= en to cover this answers the right questions, but for the > same reason, I cannot help much with actually writing it, and am hoping t= hat there are folks interested in picking up this work. > > Thanks, > Wes George > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > --=20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From randy@psg.com Sun Apr 3 21:31:46 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C134A28C0EC for ; Sun, 3 Apr 2011 21:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxIbi3N5C9nQ for ; Sun, 3 Apr 2011 21:31:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 24E8928C0E6 for ; Sun, 3 Apr 2011 21:31:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-2643.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6bSV-0006TS-PE; Mon, 04 Apr 2011 04:32:12 +0000 Date: Sun, 03 Apr 2011 21:32:11 -0700 Message-ID: From: Randy Bush To: Wes George In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6ACDF@PLSWM12A.ad.sprint.com> References: <20110401131142.GA15519@slice> <54E900DC635DAB4DB7A6D799B3C4CD8E10C6ACDF@PLSWM12A.ad.sprint.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] IETF 80 - suggestions related to expiry time and BGP implementation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 04:31:46 -0000 > How long is too long for a replay attack to go unnoticed? I'd bet that > a lot of the folks worried about this would answer in minutes, while > those concerned primarily with the hardware in their routers would > answer in hours... from the bgpsec-ops docco As beaconing places a load on the entire global routing system, careful thought MUST be given to any need to beacon frequently. This would be based on a conservative estimation of the vulnerability to a replay attack. Beacon timing and signature validity periods SHOULD be as follows: The Exemplary Citizen: Prefix originators who are not overly concerned about replay attacks might announce with a signature validity of multiple weeks and beacon one third of the validity period. Normal Prefix: Most prefixes SHOULD announce with a signature validity of a week and beacon every three days. Critical Prefix: Of course, we all think what we do is critical. But prefixes of top level DNS servers, and RPKI publication points are actually critical to large swaths of the Internet and are therefore tempting targets for replay attacks. It is suggested that the beaconing of these prefixes SHOULD be two to four hours, with a signature validity of six to twelve hours. Note that this may incur route flap damping (RFD) with current default but deprecated RFD parameters, see [I-D.ymbk-rfd-usable]. randy From hannes@juniper.net Mon Apr 4 01:31:38 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1EE3A6935 for ; Mon, 4 Apr 2011 01:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLlxw7XaYyW6 for ; Mon, 4 Apr 2011 01:31:37 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 5794F3A6940 for ; Mon, 4 Apr 2011 01:31:35 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTZmCTfMIcU1a5HlpZ/PzrTfhDnZ/xAl7@postini.com; Mon, 04 Apr 2011 01:33:19 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Mon, 4 Apr 2011 01:31:00 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 4477825AE1; Mon, 4 Apr 2011 10:32:38 +0200 (CEST) Date: Mon, 4 Apr 2011 10:32:38 +0200 From: Hannes Gredler To: Matthias Waehlisch Message-ID: <20110404083237.GA1860@juniper.net> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: John Scudder , Christopher Morrow , sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 08:31:38 -0000 On Sat, Apr 02, 2011 at 11:22:18AM +0200, Matthias Waehlisch wrote: | Hi Hannes, | | On Fri, 1 Apr 2011, Hannes Gredler wrote: | | > so i'd be much more in favour of TCP-AO or even TCP-MD5 (did i mention | > that i am no security guy ;-)), since those are the standard tools to | > protect message integrity of the BGP session itself - its already | > onboard and does not cause much userspace / userspace transport | > weirdness since both for linux and BSD its implemented in the kernel. | > | could you give a reference to both, Linux and BSD, TCP-AO | implementations? to my knowledge there are none up to date, however it has to be done at some point as TCP-MD5 for securing the base BGP session seems to be too weak as well. so my question is: "why do we need to solve the same problem (= protecting message integrity) 2 times in different ways" ? /hannes From andrei.robachevsky@gmail.com Mon Apr 4 03:27:21 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16E13A6961 for ; Mon, 4 Apr 2011 03:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7iZlVV1FhzU for ; Mon, 4 Apr 2011 03:27:14 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 89D9B3A695E for ; Mon, 4 Apr 2011 03:27:14 -0700 (PDT) Received: by ewy19 with SMTP id 19so1896392ewy.31 for ; Mon, 04 Apr 2011 03:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VkSkSDGjKQzdWljKOzfhK9OVmd3e6j12QI0w04MeQg8=; b=cHhIxnwnilX8g9iwQQvAQcrT1NszmWQCr8HW0LMxSObV4ldpSFqxk88m2agNDhbEnl t1YwwE1m8AgKx0mCG+KA/G+6Asfxi7D45MtJCJVhIUTjoPPZY4RY04rLcHrGugviJDWw qK9cor6wie7yiid1f79SXkFay6qtSktaTjdnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=YRt7It2AOXsfXuQlshH1opGHpPa+T+frw5hp0fVPTQjbcG6+3N5mJBN9SSsDlBOivo umP4YktxRj4Lc+N7C+f6u9w33utE6MXhf16GTU4VAsozQkEPWy1mGONg+F0IgqZ1dT21 rUuSdMjFvkXfts8nkpqIFRDsPkF+i7lJoYCRg= Received: by 10.213.22.148 with SMTP id n20mr1492292ebb.40.1301912935133; Mon, 04 Apr 2011 03:28:55 -0700 (PDT) Received: from Andrei-Robachevskys-MacBook-Air.local (d126092.upc-d.chello.nl [213.46.126.92]) by mx.google.com with ESMTPS id q53sm3213015eeh.25.2011.04.04.03.28.52 (version=SSLv3 cipher=OTHER); Mon, 04 Apr 2011 03:28:53 -0700 (PDT) Message-ID: <4D999D63.4060706@gmail.com> Date: Mon, 04 Apr 2011 12:28:51 +0200 From: Andrei Robachevsky User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Sandra Murphy References: <4D95C701.9010308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] suggested amendment to draft-ymbk-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 10:27:21 -0000 Sandra Murphy wrote on 01-04-11 22:24: > > > On Fri, 1 Apr 2011, Andrei Robachevsky wrote: > >> Hi, >> >> I propose the inclusion of the following requirement: >> >> 3.x A BGPsec design should not decrease the performance characteristics >> of the BGP, nor have a negative impact on the overall resilience of the >> routing system. > > Could you say how strictly you would want this requirement interpreted? > For example, I would say that not even TCP-AO has NO impact on > performance and resilience. Do you want the requirement to forbid TCP-AO? > > --Sandy, speaking as wg co-chair > I agree with the comments on the list, it was more a strawman. How about a more moderate requirement: 3.x A BGPsec design MUST provide analysis of the operational considerations for deployment with respect to the impact on the performance characteristics and the overall resilience of the routing system. This may be already implied in 3.3, but I'd like to make these two aspects more explicit. > > >> >> Examples that I have in mind is the convergence time or a solution that >> can make the global routing system more fragile (e.g. an expired >> signature blacking out a significant part of the Internet). Perhaps that >> should also be covered in the deployment considerations, since this >> depends partly on local policy decisions. >> >> Andrei >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> Andrei From danny@tcb.net Mon Apr 4 05:21:00 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A657628B23E for ; Mon, 4 Apr 2011 05:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.31 X-Spam-Level: X-Spam-Status: No, score=-110.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDuqCr-gQCju for ; Mon, 4 Apr 2011 05:20:59 -0700 (PDT) Received: from farnsworth.verisignlabs.com (farnsworth.verisignlabs.com [72.13.58.64]) by core3.amsl.com (Postfix) with ESMTP id A83BE3A69E6 for ; Mon, 4 Apr 2011 05:20:59 -0700 (PDT) Received: from monsoon.verisignlabs.com (h87.s239.verisign.com [216.168.239.87]) by farnsworth.verisignlabs.com (Postfix) with ESMTP id E2B8CA53D; Mon, 4 Apr 2011 12:22:41 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (dul1dmcphers-m2.vcorp.ad.vrsn.com [10.100.0.90]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 7BE9B2420FA; Mon, 4 Apr 2011 08:22:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <20110404083237.GA1860@juniper.net> Date: Mon, 4 Apr 2011 08:22:42 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> To: Hannes Gredler X-Mailer: Apple Mail (2.1082) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 12:21:00 -0000 On Apr 4, 2011, at 4:32 AM, Hannes Gredler wrote: > > so my question is: "why do we need to solve the same problem > (= protecting message integrity) 2 times in different ways" ? This new machinery simply introduces object-level integrity functions in the application (i.e., BGP), it does nothing to ameliorate attacks at lower layers - all those substrate attack vectors (e.g., transport connection resets, injection or replay attacks) still exist and require controls as well -- else things might break in even uglier ways at higher layers. Viva la layered security, -danny From hannes@juniper.net Mon Apr 4 05:48:42 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB583A69EA for ; Mon, 4 Apr 2011 05:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xmPlftOqdBJ for ; Mon, 4 Apr 2011 05:48:42 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 0DD733A67D1 for ; Mon, 4 Apr 2011 05:48:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTZm+j2KBhT5Byqqik0Hcf8FygZZ0wFOK@postini.com; Mon, 04 Apr 2011 05:50:24 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Mon, 4 Apr 2011 05:48:35 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 76FEA2E49B; Mon, 4 Apr 2011 14:50:16 +0200 (CEST) Date: Mon, 4 Apr 2011 14:50:16 +0200 From: Hannes Gredler To: Danny McPherson Message-ID: <20110404125015.GA3277@juniper.net> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 12:48:42 -0000 On Mon, Apr 04, 2011 at 08:22:42AM -0400, Danny McPherson wrote: | | On Apr 4, 2011, at 4:32 AM, Hannes Gredler wrote: | | > | > so my question is: "why do we need to solve the same problem | > (= protecting message integrity) 2 times in different ways" ? | | This new machinery simply introduces object-level integrity functions | in the application (i.e., BGP), it does nothing to ameliorate attacks | at lower layers - all those substrate attack vectors (e.g., transport | connection resets, injection or replay attacks) still exist and | require controls as well -- else things might break in even uglier ways | at higher layers. still that does not answer my question: why do we need to solve the problem of transport integrity twice (or to play devils advocate: shall we encapsulate BGP into SSH up until something better than MD5 is available ;-)) /hannes From Wesley.E.George@sprint.com Mon Apr 4 05:50:47 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99A03A69EE for ; Mon, 4 Apr 2011 05:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.155 X-Spam-Level: X-Spam-Status: No, score=-4.155 tagged_above=-999 required=5 tests=[AWL=-0.556, 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 2GNExMTrXvDE for ; Mon, 4 Apr 2011 05:50:40 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1outboundpool.messaging.microsoft.com [216.32.181.185]) by core3.amsl.com (Postfix) with ESMTP id ECFB13A69EA for ; Mon, 4 Apr 2011 05:50:39 -0700 (PDT) Received: from mail76-ch1-R.bigfish.com (216.32.181.170) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.8; Mon, 4 Apr 2011 12:52:22 +0000 Received: from mail76-ch1 (localhost.localdomain [127.0.0.1]) by mail76-ch1-R.bigfish.com (Postfix) with ESMTP id 0CA06708358; Mon, 4 Apr 2011 12:52:22 +0000 (UTC) X-SpamScore: -34 X-BigFish: VS-34(zz9371P542Nzz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI Received: from mail76-ch1 (localhost.localdomain [127.0.0.1]) by mail76-ch1 (MessageSwitch) id 1301921541646081_23856; Mon, 4 Apr 2011 12:52:21 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail76-ch1.bigfish.com (Postfix) with ESMTP id 8D454B5004E; Mon, 4 Apr 2011 12:52:21 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 4 Apr 2011 12:52:17 +0000 Received: from PDAWEH05.ad.sprint.com (PDAWEH05.corp.sprint.com [144.226.110.92]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p34CqGjR031287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Apr 2011 07:52:16 -0500 Received: from PDAWEH04.ad.sprint.com (144.226.111.59) by PDAWEH05.ad.sprint.com (144.226.110.92) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 4 Apr 2011 07:52:16 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH04.ad.sprint.com ([2002:90e2:6f3b::90e2:6f3b]) with mapi id 14.01.0270.001; Mon, 4 Apr 2011 07:52:16 -0500 From: "George, Wes E [NTK]" To: "carlos@lacnic.net" Thread-Topic: [sidr] BCP for implementing RPKI? Thread-Index: AcvyXbuB9it8+ktmTaaJ/hQha6BlcAALjKkAAA67jgA= Date: Mon, 4 Apr 2011 12:52:15 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6AFCE@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6AE16@PLSWM12A.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.229.76.112] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0034_01CBF2A5.9759EE10" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "sidr@ietf.org" Subject: Re: [sidr] BCP for implementing RPKI? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 12:50:47 -0000 ------=_NextPart_000_0034_01CBF2A5.9759EE10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: Carlos Martinez-Cagnazzo [mailto:carlosm3011@gmail.com] Sent: Sunday, April 03, 2011 8:49 PM To: George, Wes E [NTK] Cc: sidr@ietf.org Subject: Re: [sidr] BCP for implementing RPKI? That said, I believe documenting best practices is always a good idea. Do you think a new, different document is needed or that practices you want documented can be included in the CPS documents ? regards Carlos [WEG] I'm open to either. In looking at the current use cases doc: http://tools.ietf.org/html/draft-ietf-sidr-usecases-01 it seems to be more about the BGP side of the use cases rather than the RPKI, so either there needs to be a separate doc or this needs a new section specifically devoted to the use cases I've been referring to. ------=_NextPart_000_0034_01CBF2A5.9759EE10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDITCCAx0CAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB8DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0MDQxMjUyMTNaMCMGCSqGSIb3DQEJBDEWBBRgintVSh7C ktfSymhLROAf1qw8jzBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjCBlwYJKwYB BAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJp bnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNl IElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJEAILMYGJoIGGMHgx EzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/Is ZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRo b3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYCBYogPoy4hk/BRfLB2TWP6p5lLDQxT xPGuMuo0KZrT3ABM3usvAa2csoK9dd/J+sq0JEDnxGnyyyFp+dDWqaSLqeXenhjCjbTOBK2BTImO bflW/J/pQegl0/Lu14FIOTnX7URllDoSzT/6E+pJ68oAEuqyohIFAupHVolkbYo4WgAAAAAAAA== ------=_NextPart_000_0034_01CBF2A5.9759EE10-- From christopher.morrow@gmail.com Mon Apr 4 06:16:37 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7133A69EA for ; Mon, 4 Apr 2011 06:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfQ8WjvgnF4l for ; Mon, 4 Apr 2011 06:16:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 424A33A693B for ; Mon, 4 Apr 2011 06:16:36 -0700 (PDT) Received: by wyb29 with SMTP id 29so5235839wyb.31 for ; Mon, 04 Apr 2011 06:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/Cr6BLBycxV4hnf+cs8MlRPuCrv1xqzdSoH7QADfiVo=; b=HryN1ZPGWvL+39NPpHk33SAtYiwt8ImBmgMo8MUkr0wXumHto7jaUo40bZeakbhpPo FLp6KETN1I+uCJdiZsIihdbHk42PX7TYjTjCilUL/WIVur19HXzgJQBgGeqskH/iBH4/ plS89UZ4HQ1WkOpuHOPTfsANAQn7y54HKOT9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=QwgOMTEYqIfM3B8mhJvwsH91BAe0q7ergtSJpBwGiXqKbQltf4bj0JsVs13ioS3f3l G8pe3W6NEgfr9Fb7lWuhOmXdYhT7+rrYK2wm2DDhcup6f7kdhSB8y1W6gxG1/r9azLBt DLZPhw5PnLOvOWfBHf9cg5y81rf5B1XXUWchY= MIME-Version: 1.0 Received: by 10.216.191.168 with SMTP id g40mr204010wen.60.1301923098256; Mon, 04 Apr 2011 06:18:18 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.185.16 with HTTP; Mon, 4 Apr 2011 06:18:17 -0700 (PDT) In-Reply-To: <20110404125015.GA3277@juniper.net> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> Date: Mon, 4 Apr 2011 09:18:17 -0400 X-Google-Sender-Auth: 7AcFmua3xbisMChx9qv0iTcfnuw Message-ID: From: Christopher Morrow To: Hannes Gredler Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 13:16:37 -0000 On Mon, Apr 4, 2011 at 8:50 AM, Hannes Gredler wrote: > On Mon, Apr 04, 2011 at 08:22:42AM -0400, Danny McPherson wrote: > | > | On Apr 4, 2011, at 4:32 AM, Hannes Gredler wrote: > | > | > > | > so my question is: "why do we need to solve the same problem > | > (= protecting message integrity) 2 times in different ways" ? > | > | This new machinery simply introduces object-level integrity functions > | in the application (i.e., BGP), it does nothing to ameliorate attacks > | at lower layers - all those substrate attack vectors (e.g., transport > | connection resets, injection or replay attacks) still exist and > | require controls as well -- else things might break in even uglier ways > | at higher layers. > > still that does not answer my question: why do we need to solve the problem > of transport integrity twice (or to play devils advocate: > shall we encapsulate BGP into SSH up until something better than MD5 > is available ;-)) some folks (not me) suggest that ipsec is the way to go here... (bgp I mean) I think one point to keep in mind is that tcp-ao has exactly zero implementations... while SSH implementations abound. -chris From shane@castlepoint.net Mon Apr 4 06:38:23 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37123A69F0 for ; Mon, 4 Apr 2011 06:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 xjyxx1lN7Egr for ; Mon, 4 Apr 2011 06:38:22 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id A24C53A69EF for ; Mon, 4 Apr 2011 06:38:20 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id C8074268674; Mon, 4 Apr 2011 07:40:02 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 04 Apr 2011 07:40:02 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=50999; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6AE16@PLSWM12A.ad.sprint.com> Date: Mon, 4 Apr 2011 07:40:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <418D2577-48BE-4525-BDD4-EDF66E0FBB87@castlepoint.net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6AE16@PLSWM12A.ad.sprint.com> To: "George, Wes E [NTK]" X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org" Subject: Re: [sidr] BCP for implementing RPKI? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 13:38:23 -0000 On Apr 3, 2011, at 18:17 MDT, George, Wes E [NTK] wrote: > While we have an operational considerations document that covers = origin validation, it focuses mainly on policy and implementation > details of the validation machinery. We don't have anything that = covers the back-end of implementing a proper RPKI (from the cache > upward, rather than downward towards the router).=20 +1 > So I think that there is a need for a document that covers things like = identity and authority management, minimum levels of security > for key management, etc. +1 > I'm happy to help play the part of RPKI n00b to ensure that a draft = written to cover this answers the right questions, but for the > same reason, I cannot help much with actually writing it, and am = hoping that there are folks interested in picking up this work. +1 -shane= From randy@psg.com Mon Apr 4 08:17:59 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898A328C114 for ; Mon, 4 Apr 2011 08:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-fX5kJVfs0H for ; Mon, 4 Apr 2011 08:17:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 1FD7628C104 for ; Mon, 4 Apr 2011 08:17:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-2643.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6lXs-0008NR-2N; Mon, 04 Apr 2011 15:18:24 +0000 Date: Mon, 04 Apr 2011 08:18:23 -0700 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 15:17:59 -0000 > some folks (not me) suggest that ipsec is the way to go here... (bgp I > mean) I think one point to keep in mind is that tcp-ao has exactly > zero implementations... while SSH implementations abound. turns out that o yfv may have ssh client and server, but they do not have the library in a form usable by arbitrary apps, e.g. bgp o no ao impls on unix, slowlaris, linuxes, ... so i would really love to hear from the security folk if we can do something like hmac-md5 as the mandatory to implement. randy From kent@bbn.com Mon Apr 4 09:08:28 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8E13A683A for ; Mon, 4 Apr 2011 09:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, 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 P6U+Yck8Sddv for ; Mon, 4 Apr 2011 09:08:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 557293A682E for ; Mon, 4 Apr 2011 09:08:27 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49165) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6mLw-000LUd-6b; Mon, 04 Apr 2011 12:10:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D975BC0.9080608@cisco.com> References: <4D95C701.9010308@gmail.com> <4D95D4B6.9050704@gmail.com> <4D975BC0.9080608@cisco.com> Date: Mon, 4 Apr 2011 10:24:10 -0400 To: Russ White From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] suggested amendment to draft-ymbk-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:08:28 -0000 At 1:24 PM -0400 4/2/11, Russ White wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="------------enig5992EC3DE2163EED1CCB39EC" > > >> As it stands now, BGPSEC is opt-in. So it seems that clearly >> documenting these issues is more operative than make absolute >> requirements about them. > >Does this mean BGPSEC is not designated as a standards track document? >how can a security system actually work if it's "opt in?" It sounds like >this is an area that needs some discussion around it. > >:-) > >Russ A standards track protocol is usually mandatory to implement, but using it is a local context determination. I expect that's what was meant by opt-in. Steve From randy@psg.com Mon Apr 4 12:44:05 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563893A67A3 for ; Mon, 4 Apr 2011 12:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ltRzW-uDR0L5 for ; Mon, 4 Apr 2011 12:44:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id C8DEC3A6768 for ; Mon, 4 Apr 2011 12:44:04 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-2643.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6pic-0009Fr-J4; Mon, 04 Apr 2011 19:45:46 +0000 Date: Mon, 04 Apr 2011 12:45:46 -0700 Message-ID: From: Randy Bush To: Andrei Robachevsky In-Reply-To: <4D95C701.9010308@gmail.com> References: <4D95C701.9010308@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] suggested amendment to draft-ymbk-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:44:05 -0000 > I propose the inclusion of the following requirement: > > 3.x A BGPsec design should not decrease the performance > characteristics of the BGP, nor have a negative impact on the overall > resilience of the routing system. ok. i'll bite. i think this is worthwhile desire. but as an internet routing measurement person, i have to ask what are the performance charastics of bgp? what is the resilience of the routing system? what is to be measured, what are the units of measure, how are the measurements taken, and what are the values of these measurements in today's routing system? answer even the first two, and i am sure that ripe labs will have an answer for the rest within a week. :) randy From kent@bbn.com Mon Apr 4 12:51:49 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491E328C0DF for ; Mon, 4 Apr 2011 12:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEyIiksL10k9 for ; Mon, 4 Apr 2011 12:51:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 01F7E3A6768 for ; Mon, 4 Apr 2011 12:51:48 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49173) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6pq5-000Otb-KD; Mon, 04 Apr 2011 15:53:30 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6AE16@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6AE16@PLSWM12A.ad.sprint.com> Date: Mon, 4 Apr 2011 15:53:26 -0400 To: "George, Wes E [NTK]" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] BCP for implementing RPKI? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:51:49 -0000 At 12:17 AM +0000 4/4/11, George, Wes E [NTK] wrote: >... > >Put another way, a lot of the folks involved in this protocol's >design and implementation are already intimately familiar with how >to manage things like ROAs to ensure that the underlying trust of >the system is not compromised. A minor point: Certs are issued to represent resource holdings. ROAs are signed by cert holders to authorize route origination. So, the primary security concern in the RPKI is making sure that certs are issued to the right entities. >... > >So I think that there is a need for a document that covers things >like identity and authority management, minimum levels of security >for key management, etc. The right levels will vary, depending on where one is in the allocation hierarchy. IANA and RIRs, and NIRs need to be very careful, as they have the ability to mis-issue certs for very large blocks of addresses. Big ISPs need to be careful, because they have large allocations, but not so big as an RIR. Small ISPs and PI space holders are less of a concern, because the adverse impact of their mistakes are more limited. So, there is no one-size-fits all secruity best practices model that we can define. > >Basically, if you had to explain to someone how to ensure that the >ROAs that are being delegated are: Certs are used to represent delegation, not ROAs. >1) Delegated to the right person (right company, and person >authorized to make the changes within the company) >2) Have a reasonable assumption that they will not be >compromised once delegated (proper key management) >3) Methods for managing breaches, either due to failures in #1 >(disgruntled/former employee) or failures in #2 >How would you do it? if a CA makes an allocation error, it puts the offending certs on its CRL. >Are there existing documents we can use as a baseline and just fill >in some of the specific details in the form >of a few different use cases, such as RIR to primary resource >holder, resource holder to delegate, etc? note that the RPKI CP provides top-level guidance for CA operations (and RP behavior). Nore details about what a CA does re security appears in the CPS for each CA. For example, RIPE's CPS is available at http://www.ripe.net/lir-services/resource-management/certification/cps Steve From andrei.robachevsky@gmail.com Tue Apr 5 04:58:19 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE93D3A693A for ; Tue, 5 Apr 2011 04:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmwBxlKjTWPp for ; Tue, 5 Apr 2011 04:58:17 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 1E73F3A6932 for ; Tue, 5 Apr 2011 04:58:16 -0700 (PDT) Received: by eye13 with SMTP id 13so106953eye.31 for ; Tue, 05 Apr 2011 04:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ay5zdJbDIy/FLhWmB8ZdWQ2hx/r+vNM9o89kjCnO+gw=; b=FKWG1nUjeDRiuHfruPeerdDKrBMjbBtqCV2qfUVrBFjercme/fbylzAsUyv0NqFwTd 0oabgiKasUy6BDRhG3jxCugEaM6po10XY6STtmcRY8lk4Xed79HVAayRyhuRMvckdHsK 2tyMSp1bgRt2aptLb6jG2zv3E/pMhn5uAafpA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=biR1WG4/r0y0VVYstHQCx4cBP4q/ImzJ8Jy6fp6x9efrX5bDNoyHrQkxqQsT8RHjYW OCvyHhmLHU0s+8mWNgSMX4H1kpByjez5ZeEazUenTvTJOUJtyXw91JZ4GMBt1hzdYaYM pJV9RyIW/YAkTOMv4U3l1dvWlvCp/yxdbihDQ= Received: by 10.14.133.139 with SMTP id q11mr3736397eei.11.1302004799498; Tue, 05 Apr 2011 04:59:59 -0700 (PDT) Received: from Andrei-Robachevskys-MacBook-Air.local (d126092.upc-d.chello.nl [213.46.126.92]) by mx.google.com with ESMTPS id x54sm3942393eeh.26.2011.04.05.04.59.57 (version=SSLv3 cipher=OTHER); Tue, 05 Apr 2011 04:59:57 -0700 (PDT) Message-ID: <4D9B043B.4040702@gmail.com> Date: Tue, 05 Apr 2011 13:59:55 +0200 From: Andrei Robachevsky User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Randy Bush References: <4D95C701.9010308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] suggested amendment to draft-ymbk-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 11:58:19 -0000 Randy Bush wrote on 04-04-11 21:45: >> I propose the inclusion of the following requirement: >> >> 3.x A BGPsec design should not decrease the performance >> characteristics of the BGP, nor have a negative impact on the overall >> resilience of the routing system. > > ok. i'll bite. i think this is worthwhile desire. but as an internet > routing measurement person, i have to ask > > what are the performance charastics of bgp? what is the resilience > of the routing system? > > what is to be measured, what are the units of measure, how are the > measurements taken, and what are the values of these measurements in > today's routing system? > > answer even the first two, and i am sure that ripe labs will have an > answer for the rest within a week. :) > I think these questions worth pondering, and I don't know the answers, Randy. I suspect that you might know some of them. But submitted an adapted version, hopefully more acceptable. Andrei From randy@psg.com Tue Apr 5 05:58:28 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D960C3A6939 for ; Tue, 5 Apr 2011 05:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 MJVpfaC-Qi3M for ; Tue, 5 Apr 2011 05:58:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 582083A6919 for ; Tue, 5 Apr 2011 05:58:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q75re-000Cvl-0J; Tue, 05 Apr 2011 13:00:10 +0000 Date: Tue, 05 Apr 2011 06:00:07 -0700 Message-ID: From: Randy Bush To: Andrei Robachevsky In-Reply-To: <4D9B043B.4040702@gmail.com> References: <4D95C701.9010308@gmail.com> <4D9B043B.4040702@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] suggested amendment to draft-ymbk-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 12:58:29 -0000 >> ok. i'll bite. i think this is worthwhile desire. but as an internet >> routing measurement person, i have to ask >> >> what are the performance charastics of bgp? what is the resilience >> of the routing system? >> >> what is to be measured, what are the units of measure, how are the >> measurements taken, and what are the values of these measurements in >> today's routing system? >> >> answer even the first two, and i am sure that ripe labs will have an >> answer for the rest within a week. :) > > I think these questions worth pondering oh, indeed. many future great papers and phd theses lurk here. > I don't know the answers, Randy. I suspect that you might know some of > them. i wish. these are quite deep research questions at which many really good computer scientists are barely nibbling at the edge. as i said some years ago, The fact that very good computer scientists are studying the internet as a behavioral phenomonon should scare the hell out of us. rady From dougm.tlist@gmail.com Tue Apr 5 15:06:04 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576503A67EB for ; Tue, 5 Apr 2011 15:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+M5G4VTiUMR for ; Tue, 5 Apr 2011 15:06:03 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id A18433A67D2 for ; Tue, 5 Apr 2011 15:06:03 -0700 (PDT) Received: from 3-140.antd.nist.gov (3-140.antd.nist.gov [129.6.140.3]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p35M6Wgo013361; Tue, 5 Apr 2011 18:06:32 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Doug Montgomery In-Reply-To: Date: Tue, 5 Apr 2011 18:06:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7C4A2D12-A740-4CB5-BCA2-28D83AC78ACE@gmail.com> References: <4D95C701.9010308@gmail.com> <4D95D4B6.9050704@gmail.com> <4D975BC0.9080608@cisco.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: dougm.tlist@gmail.com Cc: sidr@ietf.org, Russ White Subject: Re: [sidr] suggested amendment to draft-ymbk-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 22:06:04 -0000 On Apr 4, 2011, at 10:24 AM, Stephen Kent wrote: > At 1:24 PM -0400 4/2/11, Russ White wrote: >> Content-Type: multipart/signed; micalg=3Dpgp-sha1; >> protocol=3D"application/pgp-signature"; >> boundary=3D"------------enig5992EC3DE2163EED1CCB39EC" >>=20 >>=20 >>> As it stands now, BGPSEC is opt-in. So it seems that clearly >>> documenting these issues is more operative than make absolute >>> requirements about them. >>=20 >> Does this mean BGPSEC is not designated as a standards track = document? >> how can a security system actually work if it's "opt in?" It sounds = like >> this is an area that needs some discussion around it. >>=20 >> :-) >>=20 >> Russ >=20 > A standards track protocol is usually mandatory to implement, but = using > it is a local context determination. I expect that's what was meant = by opt-in. Thanks Steve, that is what what I meant. =20 Clearly the hope (and value proposition) is that it is deployed farily = ubiquitously, but the design recognizes that some parts of the net might = choose not to run it, or only run part of it (simplex mode). I have yet to see a box kicked off the net for choosing to skip a = "mandatory to implement" feature. =20 I think we have to deal with the market realities, no matter what the = document's boiler plate says. dougm >=20 > Steve From bew@cisco.com Tue Apr 5 20:38:17 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8D03A685D for ; Tue, 5 Apr 2011 20:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.432 X-Spam-Level: X-Spam-Status: No, score=-110.432 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 gC-e7lpMlKGi for ; Tue, 5 Apr 2011 20:38:16 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3E8B53A684F for ; Tue, 5 Apr 2011 20:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1138; q=dns/txt; s=iport; t=1302061200; x=1303270800; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=tAkT5mcZdESPpB+UJH189aewD1d0fKOSUg8BRR+tzis=; b=XwD9r31ZqPEgrcNe2KPuaHXv1swH9S35nek8KfPdDGRj4brsmJ06iF7y Pobd+wAPxJPbTfv6Xxy2xS5hbjUDC6V49Le/54wnsLzMIwRlE73ZyqrTx EGX6oiFnV4u0XRLBfa7oJT9WG2j13IMlwN1nn+RBc4wP4lPJ0Zoqvw3fL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYIAC7gm02rRDoH/2dsb2JhbACYa40Jd6USnCeFbASFR4de X-IronPort-AV: E=Sophos;i="4.63,308,1299456000"; d="scan'208";a="331436881" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2011 03:39:59 +0000 Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p363dw86001442 for ; Wed, 6 Apr 2011 03:39:58 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 20:39:57 -0700 Message-Id: To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 03:38:17 -0000 Greetings,=20 I have a suggestion to draft-ymbk-bgpsec-reqs that is somewhat related = to Andrei's proposal, and was previously mentioned in the Friday SIDR = meeting. It also arises out of a concern that BGPSEC could make the = global routing system more fragile.=20 The proposed BGPSEC protocol includes a dependance on loosely = synchronized time. I understand that time is the easiest means of = obtaining freshness of the origin's BGPSEC signature. But it does add a = practical requirement that BGP routers be dependance on an ntp time = server, which was not the case previously. I'm sure there's a number of = strategies that can be deployed to minimize this dependance, but in any = case I suggest that the bgpsec-reqs document describe what restrictions = and/or allowances that BGPSEC has on other network services. Personally, I'm leery of making Internet routing dependent on ntp so = would prefer the requirement be no weaker than the following proposal: 3.xx A BGPSEC design MAY be dependent on network services other than BGP = (e.g., ntp) but SHOULD attempt to avoid such a dependancy. Brian From randy@psg.com Wed Apr 6 04:21:12 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E57828C0DC for ; Wed, 6 Apr 2011 04:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 9H+GWwMB+IKL for ; Wed, 6 Apr 2011 04:21:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 1C7E328C0CE for ; Wed, 6 Apr 2011 04:21:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7Qnq-0002ZD-Cd; Wed, 06 Apr 2011 11:21:38 +0000 Date: Wed, 06 Apr 2011 04:21:36 -0700 Message-ID: From: Randy Bush To: Brian Weis In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 11:21:12 -0000 > Personally, I'm leery of making Internet routing dependent on ntp so > would prefer the requirement be no weaker than the following proposal: > > 3.xx A BGPSEC design MAY be dependent on network services other than > BGP (e.g., ntp) but SHOULD attempt to avoid such a dependancy. if we want crypto level assurance, do you have a suggestion other than x.509, which depends on low precision time? for x.509 level assurance, what kind of precision does one actually need? my guess is on the order of hours. so we may not want to specifically abjure ntp, but rather express some bounds on the precision one wants. btw, from talking to largish operators, ntp is on all non-trivial routers. heck, it's even on 2511s i use for some remote oob serial craft port access. i am less sure of customers' edge routers. randy From Wesley.E.George@sprint.com Wed Apr 6 06:36:05 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F763A6938 for ; Wed, 6 Apr 2011 06:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.98 X-Spam-Level: X-Spam-Status: No, score=-3.98 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2KfumCKbJkD for ; Wed, 6 Apr 2011 06:36:04 -0700 (PDT) Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by core3.amsl.com (Postfix) with ESMTP id 859F43A67B2 for ; Wed, 6 Apr 2011 06:36:04 -0700 (PDT) Received: from mail70-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.8; Wed, 6 Apr 2011 13:37:47 +0000 Received: from mail70-va3 (localhost.localdomain [127.0.0.1]) by mail70-va3-R.bigfish.com (Postfix) with ESMTP id 99C6A1B702B9; Wed, 6 Apr 2011 13:37:47 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(z1725nz9371O542M1432Nzz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail70-va3 (localhost.localdomain [127.0.0.1]) by mail70-va3 (MessageSwitch) id 1302097043331747_26870; Wed, 6 Apr 2011 13:37:23 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.235]) by mail70-va3.bigfish.com (Postfix) with ESMTP id 1313ED2012D; Wed, 6 Apr 2011 13:36:37 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 6 Apr 2011 13:36:34 +0000 Received: from PDAWEH02.ad.sprint.com (PDAWEH02.corp.sprint.com [144.226.111.42]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p36DaHIJ010388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Apr 2011 08:36:33 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH02.ad.sprint.com ([2002:90e2:6f2a::90e2:6f2a]) with mapi id 14.01.0270.001; Wed, 6 Apr 2011 08:36:32 -0500 From: "George, Wes E [NTK]" To: Randy Bush , Brian Weis Thread-Topic: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services Thread-Index: AQHL9E0BM9hAmQW0B0mKJdmTbUBQKJRQ1HOg Date: Wed, 6 Apr 2011 13:36:32 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6C471@PLSWM12A.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.55] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001E_01CBF43E.1C8AA8B0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "sidr@ietf.org" Subject: Re: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:36:06 -0000 ------=_NextPart_000_001E_01CBF43E.1C8AA8B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Wednesday, April 06, 2011 7:22 AM To: Brian Weis Cc: sidr@ietf.org Subject: Re: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services > Personally, I'm leery of making Internet routing dependent on ntp so > would prefer the requirement be no weaker than the following proposal: > > 3.xx A BGPSEC design MAY be dependent on network services other than > BGP (e.g., ntp) but SHOULD attempt to avoid such a dependancy. btw, from talking to largish operators, ntp is on all non-trivial routers. heck, it's even on 2511s i use for some remote oob serial craft port access. i am less sure of customers' edge routers. [WEG] +1. I don't know why we're so stressed about something so simple. It's minimally a 2 line config. There are publicly available NTP servers. If we're really worried about NTP being a limiting factor in BGPSEC's implementation, we have a *much* larger problem. Wes George ------=_NextPart_000_001E_01CBF43E.1C8AA8B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDITCCAx0CAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB8DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0MDYxMzM2MzFaMCMGCSqGSIb3DQEJBDEWBBQMChMh3eyj sYZ5e2sq78TQX+2YTjBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjCBlwYJKwYB BAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJp bnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNl IElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJEAILMYGJoIGGMHgx EzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/Is ZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRo b3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYBxqBzdlS5+TFdcyY1NZz07xYNJVQ14 fCfwZli6a6R0ewjcv6jvJsN5gDu5HcEOPFyzewbn2CyQCyXrNafaKB77MD63HzfmQdY1JXyeGkDR Gd0QGz67hDNkXqdX8MZmY/mX1YRm0XvmwyAfD0UdrdD/OXiVMwElxnym9f1DlYkPDwAAAAAAAA== ------=_NextPart_000_001E_01CBF43E.1C8AA8B0-- From randy@psg.com Wed Apr 6 06:43:19 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274FE3A67B2 for ; Wed, 6 Apr 2011 06:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 d8Kpm-2jQo9l for ; Wed, 6 Apr 2011 06:43:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 69B273A69AD for ; Wed, 6 Apr 2011 06:43:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7T2b-000343-Dx; Wed, 06 Apr 2011 13:45:01 +0000 Date: Wed, 06 Apr 2011 06:45:00 -0700 Message-ID: From: Randy Bush To: "George, Wes E [NTK]" In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6C471@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6C471@PLSWM12A.ad.sprint.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:43:19 -0000 > [WEG] +1. I don't know why we're so stressed about something so > simple. not stressed out, though some coffee would help. brian is a crypto/security guy. he is validly worried that we could hit a problem. i suspect he is not too familiar with how we all config our networks, and that ntp, warts and all, is kind of assumed in all base configs. i suspect one key here is that, if the router has a time tick and loses it, it will be a looooong time before it loses sufficient accuracy that x.509 gloop will notice. and then all sorts of red flags will go up and our noc's bgp/snmp monitors will go bright red. another thought is that i am not sure we monitor time drift and ntp death in our routers. this would be a good thing if we're betting our buns on it. randy From kent@bbn.com Wed Apr 6 08:29:33 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D117E3A67FB for ; Wed, 6 Apr 2011 08:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, 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 89nyKmXhxFaY for ; Wed, 6 Apr 2011 08:29:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 439913A67E7 for ; Wed, 6 Apr 2011 08:29:33 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49168) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7UhP-000IZ5-IX; Wed, 06 Apr 2011 11:31:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 6 Apr 2011 11:06:08 -0400 To: Randy Bush From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:29:33 -0000 At 4:21 AM -0700 4/6/11, Randy Bush wrote: > > Personally, I'm leery of making Internet routing dependent on ntp so >> would prefer the requirement be no weaker than the following proposal: >> >> 3.xx A BGPSEC design MAY be dependent on network services other than >> BGP (e.g., ntp) but SHOULD attempt to avoid such a dependancy. > >if we want crypto level assurance, do you have a suggestion other than >x.509, which depends on low precision time? > >for x.509 level assurance, what kind of precision does one actually >need? my guess is on the order of hours. so we may not want to >specifically abjure ntp, but rather express some bounds on the >precision one wants. In general, the precision required for a PKI depends on the tolerance that relying parties have re expiration of certs and staleness of CRLs. During the WG meeting we received a good suggestion to call for explicit local controls for staleness of CRLs and cert expiration. Establishing conventions for path expiration granularity is consistent with that thrust. Steve From bew@cisco.com Wed Apr 6 09:00:40 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 641853A6947 for ; Wed, 6 Apr 2011 09:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.424 X-Spam-Level: X-Spam-Status: No, score=-110.424 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 6dU1lwVAu8fG for ; Wed, 6 Apr 2011 09:00:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id AEABC3A68D3 for ; Wed, 6 Apr 2011 09:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1633; q=dns/txt; s=iport; t=1302105743; x=1303315343; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vRN/A8cZkSE2Sx3d5MzrHzVgvzBaGDGAS/Xo4Mbhv+E=; b=eaXEvHCo66/33a0PIIIs2AOtgJO6GOICGDaKX2A4TmV2GqvJ6WPGEf1F AMmayxLdO0BVgXrWzUxrLexr95IM2ju7CE2aS2S23kPa2Dbpj6O4aGZoD aU5MgU+ahrQC6RwePzbvVocrMJQN/rtecxjD1tdo6fIqjp9Dir0nDj/42 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKKNnE2rRDoJ/2dsb2JhbACleHeIeZw4nEaFbASFTodu X-IronPort-AV: E=Sophos;i="4.63,311,1299456000"; d="scan'208";a="331833488" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2011 16:02:23 +0000 Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p36G2NxJ025199; Wed, 6 Apr 2011 16:02:23 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: Date: Wed, 6 Apr 2011 09:02:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A45A231-A4DB-45A7-922C-632925C11B6D@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6C471@PLSWM12A.ad.sprint.com> To: Randy Bush X-Mailer: Apple Mail (2.1082) Cc: "sidr@ietf.org" Subject: Re: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:00:40 -0000 Hi Randy, On Apr 6, 2011, at 6:45 AM, Randy Bush wrote: >> [WEG] +1. I don't know why we're so stressed about something so >> simple. >=20 > not stressed out, though some coffee would help. >=20 > brian is a crypto/security guy. he is validly worried that we could = hit > a problem. i suspect he is not too familiar with how we all config = our > networks, and that ntp, warts and all, is kind of assumed in all base > configs. I'm actually not surprised ntp is assumed in all the base configs, but I = did want to see some discussion as to whether not being able to reach an = ntp server for an indeterminate period of time was a problem. My way of example, you mentioned those old 2511's in your first reply = ... I'm pretty sure they don't retain the time over a reboot, which = means not reaching an ntp server could be serious if you were depending = on it.=20 If all your BGP routers keep reasonably accurate time all of the time = including over reboots, then ntp might not be a problem. I still think = the requirement is a good general requirement to keep in mind for = BGPSEC.=20 > i suspect one key here is that, if the router has a time tick and = loses > it, it will be a looooong time before it loses sufficient accuracy = that > x.509 gloop will notice. and then all sorts of red flags will go up = and > our noc's bgp/snmp monitors will go bright red. >=20 > another thought is that i am not sure we monitor time drift and ntp > death in our routers. this would be a good thing if we're betting our > buns on it. That's in the spirit of my concern .... Brian From randy@psg.com Wed Apr 6 09:03:56 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7ED53A6949 for ; Wed, 6 Apr 2011 09:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 muX0n9Fyc+DU for ; Wed, 6 Apr 2011 09:03:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 5A2C63A6947 for ; Wed, 6 Apr 2011 09:03:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7VEh-0003XS-0B; Wed, 06 Apr 2011 16:05:39 +0000 Date: Wed, 06 Apr 2011 09:05:38 -0700 Message-ID: From: Randy Bush To: Brian Weis In-Reply-To: <7A45A231-A4DB-45A7-922C-632925C11B6D@cisco.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6C471@PLSWM12A.ad.sprint.com> <7A45A231-A4DB-45A7-922C-632925C11B6D@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:03:56 -0000 > My way of example, you mentioned those old 2511's in your first reply > ... I'm pretty sure they don't retain the time over a reboot, which > means not reaching an ntp server could be serious if you were > depending on it. which is why redundant ntp service is available on every segment on which there are routers. and they also have remote strat 1 and 2 configured. > If all your BGP routers keep reasonably accurate time all of the time > including over reboots, then ntp might not be a problem. I still think > the requirement is a good general requirement to keep in mind for > BGPSEC. i do not think we are in strong disagreement. we just need modest text which is actually in scale with both ops and x.509, a fun reach :) randy From bew@cisco.com Wed Apr 6 17:43:07 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8BAD3A698B for ; Wed, 6 Apr 2011 17:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFneKJRDPQke for ; Wed, 6 Apr 2011 17:43:07 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 299243A6847 for ; Wed, 6 Apr 2011 17:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=919; q=dns/txt; s=iport; t=1302137091; x=1303346691; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=OV64wUKBVa4Z+dgpD8XYU+Umgq4jXTLTdDV4Lgyfy2A=; b=QV5APz59PvvZ/GbtxQq1XqGl68cijgx8vis+vndVTsLLeyd7QutaUPDD /8d5aqXsQHV/TkrKkRF3o4ySguSoFhx9j9MtiyjDqoRooMLZpqDPQ/+y4 p9sInp/Y0sGYn38tP88nPIe3IIDC97Z3EOKpKq1Tmk6jRSIvEuRQ/gdPH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPgHnU2rRDoI/2dsb2JhbACmAXeIeZ4nnHKFbASFTodv X-IronPort-AV: E=Sophos;i="4.63,313,1299456000"; d="scan'208";a="290897524" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 00:44:51 +0000 Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p370ipkX022623; Thu, 7 Apr 2011 00:44:51 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: Date: Wed, 6 Apr 2011 17:44:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> To: Randy Bush X-Mailer: Apple Mail (2.1082) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 00:43:08 -0000 On Apr 4, 2011, at 8:18 AM, Randy Bush wrote: >> some folks (not me) suggest that ipsec is the way to go here... (bgp = I >> mean) I think one point to keep in mind is that tcp-ao has exactly >> zero implementations... while SSH implementations abound. >=20 > turns out that >=20 > o yfv may have ssh client and server, but they do not have the = library > in a form usable by arbitrary apps, e.g. bgp >=20 > o no ao impls on unix, slowlaris, linuxes, ... >=20 > so i would really love to hear from the security folk if we can do > something like hmac-md5 as the mandatory to implement. Getting a new application (such as the rtr protocol) specifying hmac-md5 = mandatory to implement through a Secdir review and then the Security ADs = just won't happen. The only exception I can think of is if there were no = possible alternatives, and that's obviously not the case here. Brian=20= From randy@psg.com Wed Apr 6 17:45:06 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E671828C0D0 for ; Wed, 6 Apr 2011 17:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 15JmeHxn-0j9 for ; Wed, 6 Apr 2011 17:45:05 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 47C3C3A69CF for ; Wed, 6 Apr 2011 17:45:05 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7dN2-0005qq-So; Thu, 07 Apr 2011 00:46:49 +0000 Date: Wed, 06 Apr 2011 17:46:48 -0700 Message-ID: From: Randy Bush To: Brian Weis In-Reply-To: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 00:45:06 -0000 > Getting a new application (such as the rtr protocol) specifying > hmac-md5 mandatory to implement through a Secdir review and then the > Security ADs just won't happen. The only exception I can think of is > if there were no possible alternatives, and that's obviously not the > case here. with AO not implemented on any servers, routers not having ssh libraries, and this being a server to router protocol, what are the alternatives? randy From bew@cisco.com Wed Apr 6 21:28:24 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC4B28C0E9 for ; Wed, 6 Apr 2011 21:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul6xSw66tRi6 for ; Wed, 6 Apr 2011 21:28:22 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CBBF228C0CF for ; Wed, 6 Apr 2011 21:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1068; q=dns/txt; s=iport; t=1302150607; x=1303360207; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cN3o5h/zC7zchHVcQ9rzxWx1v/vMxTOPPAMR7zANLsg=; b=JGoBGJxl5GBlfvbScWeJNZncT2AMqZiRu1VqRBx4ybsTNjVL9bGBfUQr ovZDmMMTT+qalb1PzYcq8Ffb0pWmjSTjDa8lZzOVEZqVn7/x707Aklf12 6+pHtiYMhvueRNilfmYRRWLwEMaDI/CHOrdZxJCDpiFcZnids9wWmn3L7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHA9nU2rRDoJ/2dsb2JhbACmAXeIeZ1pnHCFbQSFUId1 X-IronPort-AV: E=Sophos;i="4.63,315,1299456000"; d="scan'208";a="332218332" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 07 Apr 2011 04:30:04 +0000 Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p374U39t018098; Thu, 7 Apr 2011 04:30:04 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: Date: Wed, 6 Apr 2011 21:30:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> To: Randy Bush X-Mailer: Apple Mail (2.1082) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 04:28:24 -0000 On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: >> Getting a new application (such as the rtr protocol) specifying >> hmac-md5 mandatory to implement through a Secdir review and then the >> Security ADs just won't happen. The only exception I can think of is >> if there were no possible alternatives, and that's obviously not the >> case here. >=20 > with AO not implemented on any servers, routers not having ssh > libraries, and this being a server to router protocol, what are the > alternatives? >=20 > randy I'm surprised IPsec hasn't been mentioned in this thread ... was it = previously discussed and rejected? Correct me if I'm wrong, but I = believe it's common for BGP routers to support IPsec and servers = definitely support IPsec. On the router side, one or two IPsec sessions = to servers should not be a burden. I'm less sure of the server IPsec = scaling properties, but I would expect a LINUX or BSD kernel to have the = scaling issues as were discussed earlier in this thread regarding SSH = but I'm no expert here. Brian From christopher.morrow@gmail.com Thu Apr 7 09:26:33 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321483A6A1C for ; Thu, 7 Apr 2011 09:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF5QVGG+nFYT for ; Thu, 7 Apr 2011 09:26:32 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id C68853A698B for ; Thu, 7 Apr 2011 09:26:31 -0700 (PDT) Received: by eye13 with SMTP id 13so980497eye.31 for ; Thu, 07 Apr 2011 09:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sBoIS9+VPRBkmdKPrqHvfurRNh0XZ5Aj2gvFNCvAeP0=; b=mMh0S5OZQKTmFDlP5y9Lv0Nj+6vz7IExUE8d9f1vBQM5cyu3/655ij0+5Gahm7Q1LK JV6L3N3XQQtCvLSrSisnUnSZjyPc2dnDgxb73t6tBhfQnzwjKDwD4qU6mTtCYlwiQvLB ZS8eyElC4Roog9iPFCj2ypbkCKPqCu1lzUw00= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=csgNv88M3r8v4KunsrVfFcku1Fh/oE2AQVhhqUbdw2OIN6ESWFn5mLSSE0dt9vP6Pj yBcHGsFNdlifCAH1DPgmalG8DLp7f3xWdO3eV00+dOVQqcxGL88iEZFSULwiZYjP/UAh tk4ZLO0vriezzPhpPTTaB5rThaYs1QyBW1+Wk= MIME-Version: 1.0 Received: by 10.213.109.209 with SMTP id k17mr535423ebp.101.1302193694187; Thu, 07 Apr 2011 09:28:14 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.213.33.81 with HTTP; Thu, 7 Apr 2011 09:28:13 -0700 (PDT) In-Reply-To: <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> Date: Thu, 7 Apr 2011 12:28:13 -0400 X-Google-Sender-Auth: ltYRq7I3HFLft8oZdFekWzxVvMk Message-ID: From: Christopher Morrow To: Brian Weis Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:26:33 -0000 On Thu, Apr 7, 2011 at 12:30 AM, Brian Weis wrote: > > On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: > >>> Getting a new application (such as the rtr protocol) specifying >>> hmac-md5 mandatory to implement through a Secdir review and then the >>> Security ADs just won't happen. The only exception I can think of is >>> if there were no possible alternatives, and that's obviously not the >>> case here. >> >> with AO not implemented on any servers, routers not having ssh >> libraries, and this being a server to router protocol, what are the >> alternatives? >> >> randy > > I'm surprised IPsec hasn't been mentioned in this thread ... was it previously see msgid: Message-ID: (5-6 messages back in this thread, from me) > discussed and rejected? Correct me if I'm wrong, but I believe it's common for > BGP routers to support IPsec and servers definitely support IPsec. On the it's not a guarantee that all bgp speakers here will have ipsec capable code... for some long time at least one vendor in their 'ISP' code didn't implement ipsec, or ssh for that matter. IPSEC is pretty heavy weight (from a config perspective) for this. Something like AO or MD5 is 'perfect', SSH as proposed does a fine job as well, though has a bugaboo on at least one platform apparently. > router side, one or two IPsec sessions to servers should not be a burden. I'm > less sure of the server IPsec scaling properties, but I would expect a LINUX > or BSD kernel to have the scaling issues as were discussed earlier in this > thread regarding SSH but I'm no expert here. lots of at-scale vpn systems are nothing but crypto-accelerators + linux/bsd underneath... I think there's an aversion to ipsec on routers (complexity and unused codepaths), ssh is 'used all the time' as is tcp-md5, as will (soon?) tcp-AO. What is a reasonable way forward for now, MUST md5 and later when AO is more ubiquitous hammer through an update to the draft? Keeping a MAY for ssh transport? (in the vein of moving this forward since running code exists for both sides of this equation today) -chris > > Brian > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Thu Apr 7 09:39:36 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6FE3A681F for ; Thu, 7 Apr 2011 09:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 YGcgxx82IzWT for ; Thu, 7 Apr 2011 09:39:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 555983A6819 for ; Thu, 7 Apr 2011 09:39:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7sGh-0008iO-Bx; Thu, 07 Apr 2011 16:41:15 +0000 Date: Thu, 07 Apr 2011 09:41:15 -0700 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:39:36 -0000 > SSH as proposed does a fine job as well, though has a bugaboo on at > least one platform apparently. two major platforms > What is a reasonable way forward for now, MUST md5 and later when AO > is more ubiquitous hammer through an update to the draft? Keeping a > MAY for ssh transport? do servers support md5/tcp? i honestly do not know other than freebsd. randy From hannes@juniper.net Thu Apr 7 10:04:30 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E6F3A6819 for ; Thu, 7 Apr 2011 10:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuEKK1shO1pH for ; Thu, 7 Apr 2011 10:04:30 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id E64383A67CF for ; Thu, 7 Apr 2011 10:04:28 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ3vA/crLw4zsEI99WgsKE/K40LDrmBJ@postini.com; Thu, 07 Apr 2011 10:06:15 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Thu, 7 Apr 2011 10:03:29 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 438FE25D4F; Thu, 7 Apr 2011 19:05:20 +0200 (CEST) Date: Thu, 7 Apr 2011 19:05:20 +0200 From: Hannes Gredler To: Randy Bush Message-ID: <20110407170519.GC7789@juniper.net> References: <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:04:31 -0000 On Thu, Apr 07, 2011 at 09:41:15AM -0700, Randy Bush wrote: | > SSH as proposed does a fine job as well, though has a bugaboo on at | > least one platform apparently. | | two major platforms | | > What is a reasonable way forward for now, MUST md5 and later when AO | > is more ubiquitous hammer through an update to the draft? Keeping a | > MAY for ssh transport? | | do servers support md5/tcp? i honestly do not know other than freebsd. support for this has been added somewhere around 2.6.27 ... http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cfb6eeb4c860592edd123fdea908d23c6ad1c7dc /hannes From randy@psg.com Thu Apr 7 10:06:29 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DA3B28C170 for ; Thu, 7 Apr 2011 10:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 UcsDRjcsTaCH for ; Thu, 7 Apr 2011 10:06:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 97BB228C161 for ; Thu, 7 Apr 2011 10:06:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7sgk-0008qW-QJ; Thu, 07 Apr 2011 17:08:11 +0000 Date: Thu, 07 Apr 2011 10:08:10 -0700 Message-ID: From: Randy Bush To: Hannes Gredler In-Reply-To: <20110407170519.GC7789@juniper.net> References: <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <20110407170519.GC7789@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:06:29 -0000 >> do servers support md5/tcp? i honestly do not know other than freebsd. > support for this has been added somewhere around 2.6.27 ... > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cfb6eeb4c860592edd123fdea908d23c6ad1c7dc looks like penguin stuff. what about unixes? solaris? randy From Donald.Smith@qwest.com Thu Apr 7 10:15:12 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1BA3A67CF for ; Thu, 7 Apr 2011 10:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 q2dVBtcGSVdh for ; Thu, 7 Apr 2011 10:15:11 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id C972E3A67B0 for ; Thu, 7 Apr 2011 10:15:11 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id p37HGshO014462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Apr 2011 11:16:55 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id DD0781E0055; Thu, 7 Apr 2011 11:16:49 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id C2DF31E0060; Thu, 7 Apr 2011 11:16:49 -0600 (MDT) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id p37HGmQ3012057; Thu, 7 Apr 2011 11:16:49 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Thu, 7 Apr 2011 11:16:44 -0600 From: "Smith, Donald" To: "'Randy Bush'" , "'Christopher Morrow'" Date: Thu, 7 Apr 2011 11:16:43 -0600 Thread-Topic: [sidr] WGLC draft-sidr-rpki-rtr - take 2? Thread-Index: Acv1QqJHSDOaLar7ToS6eVg1h88pIQABGE3A Message-ID: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@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-CFilter-Loop: Reflected Cc: 'sidr wg list' Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:15:12 -0000 Sharing: Author's permission required. Donald.Smith@qwest.com > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Randy Bush > Sent: Thursday, April 07, 2011 10:41 AM > To: Christopher Morrow > Cc: sidr wg list > Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > > > SSH as proposed does a fine job as well, though has a bugaboo on at > > least one platform apparently. > > two major platforms > > > What is a reasonable way forward for now, MUST md5 and later when AO > > is more ubiquitous hammer through an update to the draft? Keeping a > > MAY for ssh transport? > > do servers support md5/tcp? i honestly do not know other than freebsd. Depends on what they are using for BGP but given that most will use Quagga = since it supports md5 you should be able to get md5 support in most server = OSes. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From hannes@juniper.net Thu Apr 7 10:29:55 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495723A698B for ; Thu, 7 Apr 2011 10:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmeNQ8Oa015r for ; Thu, 7 Apr 2011 10:29:54 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id DD5F23A6823 for ; Thu, 7 Apr 2011 10:29:52 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ309zMOIsM/zbxfl0M6QAo3pJzaWYdL@postini.com; Thu, 07 Apr 2011 10:31:39 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Thu, 7 Apr 2011 10:27:36 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 61EEB2626A; Thu, 7 Apr 2011 19:29:27 +0200 (CEST) Date: Thu, 7 Apr 2011 19:29:27 +0200 From: Hannes Gredler To: Randy Bush Message-ID: <20110407172926.GA7998@juniper.net> References: <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <20110407170519.GC7789@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 17:29:55 -0000 On Thu, Apr 07, 2011 at 10:08:10AM -0700, Randy Bush wrote: | >> do servers support md5/tcp? i honestly do not know other than freebsd. | > support for this has been added somewhere around 2.6.27 ... | > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cfb6eeb4c860592edd123fdea908d23c6ad1c7dc | | looks like penguin stuff. what about unixes? solaris? no idea; From bew@cisco.com Thu Apr 7 15:29:39 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B690F3A69B9 for ; Thu, 7 Apr 2011 15:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.474 X-Spam-Level: X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsWygUd4H452 for ; Thu, 7 Apr 2011 15:29:38 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 687A53A69B1 for ; Thu, 7 Apr 2011 15:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=3067; q=dns/txt; s=iport; t=1302215483; x=1303425083; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lWWEsUanVC96mXbDtkBQ+VLbLaOrT0FjW3Dv94wQ5ks=; b=IqUgIA0B+/WVd+gy4rlVKJwO0Mf9V5Qpn3FW1J5ndWnBVuDBSA3hRxzd 9c6EL8YigMFViolMkovz1H5Gq6WmSzV0U/cr8NdKOLNlmvjv+nN2h8gS3 SKv8gC4/nxilxVEsu13B1eB245QMlGAtfnXebM1J4PLRNFemt+8uVv5Ne 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFc6nk2rRDoJ/2dsb2JhbACmEXeIeZt2nE6FbQSFUod4 X-IronPort-AV: E=Sophos;i="4.63,319,1299456000"; d="scan'208";a="425941376" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 07 Apr 2011 22:31:23 +0000 Received: from dhcp-128-107-151-120.cisco.com (dhcp-128-107-151-120.cisco.com [128.107.151.120]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p37MURE5013682; Thu, 7 Apr 2011 22:31:23 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: Date: Thu, 7 Apr 2011 15:31:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1082) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 22:29:39 -0000 On Apr 7, 2011, at 9:28 AM, Christopher Morrow wrote: > On Thu, Apr 7, 2011 at 12:30 AM, Brian Weis wrote: >>=20 >> On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: >>=20 >>>> Getting a new application (such as the rtr protocol) specifying >>>> hmac-md5 mandatory to implement through a Secdir review and then = the >>>> Security ADs just won't happen. The only exception I can think of = is >>>> if there were no possible alternatives, and that's obviously not = the >>>> case here. >>>=20 >>> with AO not implemented on any servers, routers not having ssh >>> libraries, and this being a server to router protocol, what are the >>> alternatives? >>>=20 >>> randy >>=20 >> I'm surprised IPsec hasn't been mentioned in this thread ... was it = previously >=20 > see msgid: Message-ID: = > (5-6 messages back in this thread, from me) >=20 >> discussed and rejected? Correct me if I'm wrong, but I believe it's = common for >> BGP routers to support IPsec and servers definitely support IPsec. On = the >=20 > it's not a guarantee that all bgp speakers here will have ipsec > capable code... for some long time at least one vendor in their 'ISP' > code didn't implement ipsec, or ssh for that matter. IPSEC is pretty > heavy weight (from a config perspective) for this. Something like AO > or MD5 is 'perfect', SSH as proposed does a fine job as well, though > has a bugaboo on at least one platform apparently. I agree AO would be a great choice, but you'd probably want to wait for = implementations. Maybe mandating it would spur the implementations. :-) >=20 >> router side, one or two IPsec sessions to servers should not be a = burden. I'm >> less sure of the server IPsec scaling properties, but I would expect = a LINUX >> or BSD kernel to have the scaling issues as were discussed earlier in = this >> thread regarding SSH but I'm no expert here. >=20 > lots of at-scale vpn systems are nothing but crypto-accelerators + > linux/bsd underneath... I think there's an aversion to ipsec on > routers (complexity and unused codepaths), ssh is 'used all the time' > as is tcp-md5, as will (soon?) tcp-AO. >=20 > What is a reasonable way forward for now, MUST md5 and later when AO > is more ubiquitous hammer through an update to the draft? Keeping a > MAY for ssh transport? Possibly the use of md5 would be more palatable to the security area if = the protocol were Experimental rather than Standards-Track. If the = authors and chairs would be willing to make that change, it would be = worth asking the Security ADs what they think. Then revision it to be = standards track later when AO can be mandated. Brian=20 >=20 > (in the vein of moving this forward since running code exists for both > sides of this equation today) >=20 > -chris >=20 >>=20 >> Brian >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 From randy@psg.com Thu Apr 7 15:42:39 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D6E28C120 for ; Thu, 7 Apr 2011 15:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 rYiOorNBog9i for ; Thu, 7 Apr 2011 15:42:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 0628028C175 for ; Thu, 7 Apr 2011 15:42:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7xw6-000A2V-DR; Thu, 07 Apr 2011 22:44:22 +0000 Date: Thu, 07 Apr 2011 15:44:21 -0700 Message-ID: From: Randy Bush To: Brian Weis In-Reply-To: <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 22:42:39 -0000 > Possibly the use of md5 would be more palatable to the security area > if the protocol were Experimental rather than Standards-Track. If the > authors and chairs would be willing to make that change not a chance in hell. the vendors went out on a limb. operators same. randy From christopher.morrow@gmail.com Thu Apr 7 18:38:42 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3A73A69A1 for ; Thu, 7 Apr 2011 18:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUjRunVzhNNf for ; Thu, 7 Apr 2011 18:38:42 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C5D303A6934 for ; Thu, 7 Apr 2011 18:38:41 -0700 (PDT) Received: by wyb29 with SMTP id 29so2969486wyb.31 for ; Thu, 07 Apr 2011 18:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UzQYvURZ3SvoXtFAY5IY+TOtAVe3czTrmoMh9orMWGI=; b=RH0v8DKN1zkrE8W/gTaEylyFaxlLn/ilmRnOhzJ7Eq5GWCfzFFZVB/jbxNS9kUc7+w gFonf6+1W4YKzWFfwylV0+wdU17L2PpAOqChN+UJe63uVsGjvnNOgrK52M87VI+dGP19 mKp21e82cjtz7oTCWS6m7NKuKD533i6pW3+tg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=JzBoPqi0SuGstXvLYsjzJ1Oe/DeChZyeq0z+BFxjQ4MnjlEAyWG9qK1I6bCY/T+p/p uBtznL7URtskfgrQRQH2iH8dYqO80XXUxKE9WpmoSSyTPtZeKd2C0yKqBfyDOsZ2arOP dN35U3U0GW1KqL9jxFfYiMXUUgD04QIgfaXjw= MIME-Version: 1.0 Received: by 10.216.159.141 with SMTP id s13mr1341759wek.17.1302226825994; Thu, 07 Apr 2011 18:40:25 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.13.131 with HTTP; Thu, 7 Apr 2011 18:40:25 -0700 (PDT) In-Reply-To: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> Date: Thu, 7 Apr 2011 21:40:25 -0400 X-Google-Sender-Auth: fHLnWuuVnrXpcLgXslxTLFElT1o Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 01:38:42 -0000 On Thu, Apr 7, 2011 at 6:44 PM, Randy Bush wrote: >> Possibly the use of md5 would be more palatable to the security area >> if the protocol were Experimental rather than Standards-Track. =A0If the >> authors and chairs would be willing to make that change > > not a chance in hell. =A0the vendors went out on a limb. =A0operators sam= e. yea, so ... without my co-chair-special-garments on I'm not sure experimental heads us in the direction of ubiquitous secure interdomain routing. We seem to be in a bit of a jam :( I don't think SIDR is going to be able to, by declaration, get opensource implementations of AO to appear. I don't see non-open-source implementations on the server side for tcp-md5 sadly either, but at least fbsd/obsd/linux have tcp-md5 support. -chris From pmohapat@cisco.com Thu Apr 7 21:18:10 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 486803A6A38 for ; Thu, 7 Apr 2011 21:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2WAYpoCp+OM for ; Thu, 7 Apr 2011 21:18:09 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8FE063A6784 for ; Thu, 7 Apr 2011 21:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=516; q=dns/txt; s=iport; t=1302236394; x=1303445994; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=F04BBBP9IW+2pPyTsDdbloqmTlHe3gQucJUNFX7kok8=; b=e58v73qMQ/QCGhe1VSeHT/StLtDaCoMvsB1XWLkUwVdbiBnC63+7kRmM 1oVGzmF/vR+bqqb+dbaGGzI2CDS53+repRlpkFrt28yXhCv3DeKRdkBdE +F1rAc9iXLrMPQvJGfP6jPXszDPPWaxWVsYeKdJgcpLLK+0DwohinKX8j U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN6Lnk2rRDoG/2dsb2JhbACmEXeIeZo9nFOFbQSFUod4 X-IronPort-AV: E=Sophos;i="4.63,322,1299456000"; d="scan'208";a="291847126" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2011 04:19:51 +0000 Received: from sjc-vpn7-897.cisco.com (sjc-vpn7-897.cisco.com [10.21.147.129]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p384JpUS024045; Fri, 8 Apr 2011 04:19:51 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: Date: Thu, 7 Apr 2011 21:20:05 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1081) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 04:18:10 -0000 > We seem to be in a bit of a jam :( I don't think SIDR is going to be > able to, by declaration, get opensource implementations of AO to > appear. I don't see non-open-source implementations on the server side > for tcp-md5 sadly either, but at least fbsd/obsd/linux have tcp-md5 > support. We don't seem to be converging. I would suggest that we keep the status quo and make ssh mandatory to implement. Other mechanisms may get prescribed in future as & when they become commonly available. - Pradosh From christopher.morrow@gmail.com Thu Apr 7 21:36:37 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF513A69ED for ; Thu, 7 Apr 2011 21:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.388 X-Spam-Level: X-Spam-Status: No, score=-103.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdY3Cn7SDmlW for ; Thu, 7 Apr 2011 21:36:36 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 7D3E73A6784 for ; Thu, 7 Apr 2011 21:36:36 -0700 (PDT) Received: by wwa36 with SMTP id 36so2673008wwa.13 for ; Thu, 07 Apr 2011 21:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eajuygSIk+w+pCDo9dpBtbboXvwZxqytQSv9O6xR7s8=; b=RQ4/I5ApGJKnGrEf1SZ7QgtDDCak7wxZu8wxUNUH+XOgqutgrhU/QXmLoOMG5Wa7hT px2+47T6CTp0zYTtWiQpf79FTAPlOux0ypu5jXRKVUPdc3Mt8aMewu6xt0WjX9owylpO i8/U93kAZQXr8KC/bqD+8qZYC5OvyHuqmWy3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=tilrtuSbS6vFhwW6BR13fIea3tyqgxbBK4jVt5Q5u9nol+d1vkNQ41Z81Dc0kTIoYP XAN0ErVV4TwgoEjCdk1A9+vn+2K0nnAchoVSemjteoyGXK+nlKZgvUfsPLtee7LQ5iOy PcgijEQGI6HfOdlLSfqVt4Sr58vCRfWQVRe30= MIME-Version: 1.0 Received: by 10.216.168.82 with SMTP id j60mr1456070wel.47.1302237500976; Thu, 07 Apr 2011 21:38:20 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.13.131 with HTTP; Thu, 7 Apr 2011 21:38:20 -0700 (PDT) In-Reply-To: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> Date: Fri, 8 Apr 2011 00:38:20 -0400 X-Google-Sender-Auth: nYKShg0RxyylxA0MWYpjHG1i05w Message-ID: From: Christopher Morrow To: Pradosh Mohapatra Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 04:36:37 -0000 On Fri, Apr 8, 2011 at 12:20 AM, Pradosh Mohapatra wrote: >> We seem to be in a bit of a jam :( I don't think SIDR is going to be >> able to, by declaration, get opensource implementations of AO to >> appear. I don't see non-open-source implementations on the server side >> for tcp-md5 sadly either, but at least fbsd/obsd/linux have tcp-md5 >> support. > > We don't seem to be converging. I would suggest that we keep the status quo > and make ssh mandatory to implement. Other mechanisms may get prescribed > in future as & when they become commonly available. sounds ok to me. From Internet-Drafts@ietf.org Thu Apr 7 23:45:05 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51803A6A45; Thu, 7 Apr 2011 23:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWzl-PYhYiuw; Thu, 7 Apr 2011 23:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712393A685D; Thu, 7 Apr 2011 23:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.16 Message-ID: <20110408064501.9278.35265.idtracker@localhost> Date: Thu, 07 Apr 2011 23:45:01 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-iana-objects-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 06:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI Objects issued by IANA Author(s) : T. Manderson, et al. Filename : draft-ietf-sidr-iana-objects-02.txt Pages : 22 Date : 2011-04-07 This document provides specific direction to IANA as to the Resource Public Key Infrastructure (RPKI) objects it should issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-iana-objects-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-iana-objects-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-07233535.I-D@ietf.org> --NextPart-- From terry.manderson@icann.org Thu Apr 7 23:48:10 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18BB13A6989 for ; Thu, 7 Apr 2011 23:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P4OroLua7t2 for ; Thu, 7 Apr 2011 23:48:09 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 395503A6A3D for ; Thu, 7 Apr 2011 23:48:09 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 7 Apr 2011 23:49:54 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Thu, 7 Apr 2011 23:49:42 -0700 Thread-Topic: [sidr] I-D Action:draft-ietf-sidr-iana-objects-02.txt Thread-Index: Acv1uMtep7P7O1JmQIe9V3FFI4cUOQAAFfvR Message-ID: In-Reply-To: <20110408064501.9278.35265.idtracker@localhost> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_C9C4ED27E33Fterrymandersonicannorg_" MIME-Version: 1.0 Subject: Re: [sidr] I-D Action:draft-ietf-sidr-iana-objects-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 06:48:10 -0000 --_002_C9C4ED27E33Fterrymandersonicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Version rev to address DISCUSS items in IESG review. Diff attached as FYI. Cheers Terry On 8/04/11 4:45 PM, "Internet-Drafts@ietf.org" wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Inter-Domain Routing Working Grou= p of > the IETF. >=20 >=20 > Title : RPKI Objects issued by IANA > Author(s) : T. Manderson, et al. > Filename : draft-ietf-sidr-iana-objects-02.txt > Pages : 22 > Date : 2011-04-07 >=20 > This document provides specific direction to IANA as to the Resource > Public Key Infrastructure (RPKI) objects it should issue. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-iana-objects-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --_002_C9C4ED27E33Fterrymandersonicannorg_ Content-Type: application/octet-stream; name="draft-ietf-sidr-iana-objects-02-from-1.diff.html" Content-Description: draft-ietf-sidr-iana-objects-02-from-1.diff.html Content-Disposition: attachment; filename="draft-ietf-sidr-iana-objects-02-from-1.diff.html"; size=92218; creation-date="Thu, 07 Apr 2011 23:49:54 GMT"; modification-date="Thu, 07 Apr 2011 23:49:54 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPiAKPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjQxOiByZmNkaWZmICAtLT4gCjwh LS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsIiA+IC0tPgo8IS0tIFN5c3RlbTogRGFyd2luIHRlcnJ5LW1hbmRlcnNvbnMtbWFjYm9vay5s b2NhbCAxMC42LjAgRGFyd2luIEtlcm5lbCBWZXJzaW9uIDEwLjYuMDogV2VkIE5vdiAxMCAxODox MzoxNyBQU1QgMjAxMDsgcm9vdDp4bnUtMTUwNC45LjI2fjMvUkVMRUFTRV9JMzg2IGkzODYgLS0+ IAo8IS0tIFVzaW5nIGF3azogL29wdC9sb2NhbC9iaW4vZ2F3azogR05VIEF3ayAzLjEuOCAtLT4g CjwhLS0gVXNpbmcgZGlmZjogL3Vzci9iaW4vZGlmZjogZGlmZiAoR05VIGRpZmZ1dGlscykgMi44 LjEgLS0+IAo8IS0tIFVzaW5nIHdkaWZmOiAvb3B0L2xvY2FsL2Jpbi93ZGlmZjogd2RpZmYgKEdO VSB3ZGlmZikgMC42LjMgLS0+IAo8aHRtbD4gCjxoZWFkPiAKICA8bWV0YSBodHRwLWVxdWl2PSJD b250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiAvPiAK ICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVN0eWxlLVR5cGUiIGNvbnRlbnQ9InRleHQvY3Nz IiAvPiAKICA8dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1zaWRyLWlhbmEtb2JqZWN0cy0wMS50eHQg LSBkcmFmdC1pZXRmLXNpZHItaWFuYS1vYmplY3RzLTAyLnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0 eXBlPSJ0ZXh0L2NzcyI+IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdo dDogYXV0bzsgfSAKICAgIHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBw cmU7IGZvbnQtZmFtaWx5OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6 ZTogMC44NmVtO30gCiAgICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAgICAuc21h bGwgIHsgZm9udC1zaXplOiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTog VmVyZGFuYSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQgICB7IGJhY2tncm91 bmQtY29sb3I6ICNFRUU7IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsg fSAKICAgIC5kaWZmICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IAogICAgLmxibG9jayB7 IGJhY2tncm91bmQtY29sb3I6ICNCRkI7IH0gCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xv cjogI0ZGODsgfSAKICAgIC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEZGOyB9IAogICAg LmRlbGV0ZSB7IGJhY2tncm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dy b3VuZC1jb2xvcjogI0ZGQjsgfSAKICAgIC5jb250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVF OyB9IAogICAgLmxpbmViciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5v IHsgY29sb3I6IHJlZDsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsg dGV4dC1hbGlnbjogcmlnaHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tn cm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6 ICNEREQ7IH0gCiAgICAucmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAog ICAgLmxibG9jayAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2Nr IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQt Y29sb3I6ICM4QUQ7IH0gCiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dy b3VuZC1jb2xvcjogI0VFRTsgcGFkZGluZzogMnB4IDA7IH0gCiAgPC9zdHlsZT4gCjwvaGVhZD4g Cjxib2R5ID4gCiAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIwIj4gCiAgPHRyIGJnY29sb3I9Im9yYW5nZSI+PHRoPjwvdGg+PHRoPiZuYnNwO2RyYWZ0LWll dGYtc2lkci1pYW5hLW9iamVjdHMtMDEudHh0Jm5ic3A7PC90aD48dGg+IDwvdGg+PHRoPiZuYnNw O2RyYWZ0LWlldGYtc2lkci1pYW5hLW9iamVjdHMtMDIudHh0Jm5ic3A7PC90aD48dGg+PC90aD48 L3RyPiAKICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5OZXR3b3JrIFdvcmtp bmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBULiBNYW5kZXJz b248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5OZXR3b3JrIFdvcmtpbmcgR3JvdXAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBULiBNYW5kZXJzb248L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTC4g VmVnb2RhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTC4gVmVnb2RhPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVu ZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBJQ0FOTjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVuZGVkIHN0YXR1 czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJQ0FO TjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDEiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5FeHBpcmVzOiA8 c3BhbiBjbGFzcz0iZGVsZXRlIj5BdWd1c3QgMjAsIDIwMTEgPC9zcGFuPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBLZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPkV4cGlyZXM6IDxzcGFuIGNsYXNzPSJpbnNlcnQiPk9jdG9iZXIgMTAsIDIwMTE8 L3NwYW4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFMuIEtlbnQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQkJOPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQkJO PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZD48YSBuYW1lPSJkaWZmMDAwMiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5GZWJydWFyeSAxNjwvc3Bhbj4sIDIwMTE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICBBcHJpbCA4PC9zcGFuPiwgMjAxMTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgIFJQS0kgT2JqZWN0 cyBpc3N1ZWQgYnkgSUFOQTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAg ICAgICAgICAgICAgICBSUEtJIE9iamVjdHMgaXNzdWVkIGJ5IElBTkE8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRp ZmYwMDAzIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0 Zi1zaWRyLWlhbmEtb2JqZWN0cy0wPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTwvc3Bhbj4udHh0PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgIGRyYWZ0LWll dGYtc2lkci1pYW5hLW9iamVjdHMtMDxzcGFuIGNsYXNzPSJpbnNlcnQiPjI8L3NwYW4+LnR4dDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QWJzdHJhY3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij5BYnN0cmFjdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBk b2N1bWVudCBwcm92aWRlcyBzcGVjaWZpYyBkaXJlY3Rpb24gdG8gSUFOQSBhcyB0byB0aGUgUmVz b3VyY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IHBy b3ZpZGVzIHNwZWNpZmljIGRpcmVjdGlvbiB0byBJQU5BIGFzIHRvIHRoZSBSZXNvdXJjZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQdWJs aWMgS2V5IEluZnJhc3RydWN0dXJlIChSUEtJKSBvYmplY3RzIGl0IHNob3VsZCBpc3N1ZS48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJl IChSUEtJKSBvYmplY3RzIGl0IHNob3VsZCBpc3N1ZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPlN0YXR1cyBvZiB0aGlzIE1lbW88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5T dGF0dXMgb2YgdGhpcyBNZW1vPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIElu dGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBz dWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcm92aXNpb25zIG9mIEJDUCA3 OCBhbmQgQkNQIDc5LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHByb3Zpc2lv bnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0 aD48YSBuYW1lPSJwYXJ0LWwyIiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxs PjxlbT4gcGFnZSAxLCBsaW5lIDMzPC9lbT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFy dC1yMiIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMSwg bGluZSAzMzwvZW0+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRz IGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcg ZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUYXNrIEZvcmNlIChJRVRGKS4g IE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVy IGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0 LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAg VGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMv Y3VycmVudC8uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1EcmFmdHMg YXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHM8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0 IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIG1heSBiZSB1 cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnk8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJl cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQg aXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRl IHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUg dGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEg bmFtZT0iZGlmZjAwMDQiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGlzIEludGVybmV0LURy YWZ0IHdpbGwgZXhwaXJlIG9uIDxzcGFuIGNsYXNzPSJkZWxldGUiPkF1Z3VzdCAyPC9zcGFuPjAs IDIwMTEuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgd2lsbCBleHBpcmUgb24gPHNwYW4gY2xhc3M9Imluc2VydCI+T2N0b2JlciAxPC9zcGFu PjAsIDIwMTEuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5Db3B5cmlnaHQgTm90aWNlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29weXJpZ2h0IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRo ZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgQ29weXJpZ2h0IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50 aWZpZWQgYXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmln aHRzIHJlc2VydmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVu dCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBC Q1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJ RVRGIERvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFByb3Zpc2lv bnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xp Y2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4g ZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVh c2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRv Y3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1s MyIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMiwgbGlu ZSAyMjwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjMiIC8+PHNtYWxsPnNr aXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDIsIGxpbmUgMjI8L2VtPjwvdGg+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDYuICBVbmFsbG9jYXRlZCBSZXNvdXJjZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgODwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIDYuICBVbmFsbG9jYXRlZCBSZXNvdXJjZXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA3LiAgU3BlY2lhbCBQdXJwb3NlIFJlZ2lzdHJ5 IFJlc291cmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDk8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICA3LiAgU3BlY2lhbCBQdXJwb3NlIFJlZ2lzdHJ5IFJlc291cmNl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgOC4gIE11bHRpY2FzdCAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgOC4gIE11bHRpY2FzdCAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDkuICBJbmZvcm1hdGlvbmFsIE9i amVjdHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDkuICBJbmZvcm1hdGlvbmFsIE9iamVjdHMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAxMC4gQ2VydGlmaWNhdGVz IGFuZCBDUkxzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTI8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAxMC4gQ2VydGlmaWNhdGVzIGFuZCBDUkxz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTI8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMTEuIElBTkEgQ29u c2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEz PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMTEuIElBTkEgQ29uc2lkZXJhdGlv bnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDEyLiBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDEyLiBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAxMy4g QWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAxMy4gQWNrbm93bGVk Z2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg MTQuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDE2PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMTQuIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDE2PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgMTQuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMTQu MS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDUiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg IDE0LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgICAgMTQuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNjwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTk8L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEFwcGVuZGl4IEEu ICBJQU5BIFJlc2VydmVkIElQdjQgQWRkcmVzcyBCbG9ja3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAx OTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgQXBwZW5kaXggQi4gIElBTkEgUmVzZXJ2ZWQgSVB2NiBBZGRyZXNzIEJsb2NrcyAu IC4gLiAuIC4gLiAuIC4gLiAuIDIwPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9Imluc2VydCI+MjI8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xLiAgUmVxdWlyZW1lbnRzIE5vdGF0aW9uPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+MS4gIFJlcXVpcmVtZW50cyBOb3RhdGlvbjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJS RVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAi U0hBTEwiLCAiU0hBTEwgTk9UIiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVE IiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwg YW5kICJPUFRJT05BTCIgaW4gdGhpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMg ZGVzY3JpYmVkIGluIFtSRkMyMTE5XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5 XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjIuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4yLiAgSW50cm9kdWN0aW9uPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBBbiBJbmZyYXN0cnVjdHVyZSB0byBTdXBwb3J0IFNlY3VyZSBJbnRlcm5l dCBSb3V0aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQW4gSW5mcmFzdHJ1 Y3R1cmUgdG8gU3VwcG9ydCBTZWN1cmUgSW50ZXJuZXQgUm91dGluZzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9Imdy YXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sNCIgLz48c21hbGw+c2tpcHBpbmcgdG8g Y2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgNywgbGluZSAxMDwvZW0+PC90aD48dGg+IDwvdGg+ PHRoPjxhIG5hbWU9InBhcnQtcjQiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21h bGw+PGVtPiBwYWdlIDcsIGxpbmUgMTA8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAiTm90IGludGVuZGVkIHRvIGJlIChwdWJs aWNseSkgcm91dGVkIjogVGhpcyBwaHJhc2UgcmVmZXJzIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgIk5vdCBpbnRlbmRlZCB0byBiZSAocHVibGljbHkpIHJvdXRlZCI6IFRo aXMgcGhyYXNlIHJlZmVycyB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcmVmaXhlcyB0aGF0IGFyZSBub3QgbWVhbnQgdG8gYmUgcmVw cmVzZW50ZWQgaW4gdGhlIGdsb2JhbCBJbnRlcm5ldDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIHByZWZpeGVzIHRoYXQgYXJlIG5vdCBtZWFudCB0byBiZSByZXByZXNlbnRlZCBp biB0aGUgZ2xvYmFsIEludGVybmV0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJvdXRpbmcgdGFibGUgKGZvciBleGFtcGxlIDE5Mi4xNjgv MTYsIFtSRkMxOTE4XSkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcm91dGlu ZyB0YWJsZSAoZm9yIGV4YW1wbGUgMTkyLjE2OC8xNiwgW1JGQzE5MThdKS48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjUuICBSZXNlcnZlZCBSZXNvdXJjZXM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij41LiAgUmVzZXJ2ZWQgUmVzb3VyY2VzPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBSZXNlcnZlZCBJUHY0IGFuZCBJUHY2IHJlc291cmNlcyBhcmUgaGVsZCBiYWNr IGZvciB2YXJpb3VzIHJlYXNvbnMgYnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBSZXNlcnZlZCBJUHY0IGFuZCBJUHY2IHJlc291cmNlcyBhcmUgaGVsZCBiYWNrIGZvciB2YXJp b3VzIHJlYXNvbnMgYnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgSUVURiBhY3Rpb24uICBHZW5lcmFsbHkgc3VjaCByZXNvdXJjZXMgYXJl IG5vdCBpbnRlbmRlZCB0byBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElF VEYgYWN0aW9uLiAgR2VuZXJhbGx5IHN1Y2ggcmVzb3VyY2VzIGFyZSBub3QgaW50ZW5kZWQgdG8g YmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgZ2xvYmFsbHkgcm91dGVkLiAgQW4gZXhhbXBsZSBvZiBzdWNoIGEgcmVzZXJ2YXRpb24gaXMg MTI3LjAuMC4wLzg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBnbG9iYWxseSBy b3V0ZWQuICBBbiBleGFtcGxlIG9mIHN1Y2ggYSByZXNlcnZhdGlvbiBpcyAxMjcuMC4wLjAvODwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQ+PGEgbmFtZT0iZGlmZjAwMDYiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBbUkZDNTczNV0u PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFtSRkM1NzM1XS4gIDxzcGFuIGNs YXNzPSJpbnNlcnQiPlNlZSBBcHBlbmRpeCBBIChBcHBlbmRpeCBBKSBhbmQgQiAoQXBwZW5kaXgg QikgZm9yIElBTkE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgIHJlc2VydmVkIHJlc291cmNlcy48L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBJQU5BIFNIT1VMRCBpc3N1ZSBhbiBBUzAgUk9BIGZvciBhbGwg cmVzZXJ2ZWQgSVB2NCBhbmQgSVB2NiByZXNvdXJjZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBJQU5BIFNIT1VMRCBpc3N1ZSBhbiBBUzAgUk9BIGZvciBhbGwgcmVzZXJ2ZWQg SVB2NCBhbmQgSVB2NiByZXNvdXJjZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbm90IGludGVuZGVkIHRvIGJlIHJvdXRlZC48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBub3QgaW50ZW5kZWQgdG8gYmUgcm91dGVkLjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlcmUgYXJlIGEgc21hbGwgbnVtYmVyIG9m IHJlc2VydmVkIHJlc291cmNlcyB3aGljaCBhcmUgaW50ZW5kZWQgdG88L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGVyZSBhcmUgYSBzbWFsbCBudW1iZXIgb2YgcmVzZXJ2ZWQg cmVzb3VyY2VzIHdoaWNoIGFyZSBpbnRlbmRlZCB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDciIC8+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBiZSByb3V0ZWQsIGZvciBleGFtcGxlIDE5Mi44OC45OS4w LzI0IFtSRkMzMDY4XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYmUgcm91 dGVkLCBmb3IgZXhhbXBsZSAxOTIuODguOTkuMC8yNCBbUkZDMzA2OF0uICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5TZWUgQXBwZW5kaXggQTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgKEFwcGVuZGl4IEEpIGFuZCBCIChBcHBlbmRp eCBCKSBmb3IgSUFOQSByZXNlcnZlZCByZXNvdXJjZXMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgSUFOQSBNVVNUIE5PVCBpc3N1ZSBhbnkgUk9BcyAoQVMwIG9yIG90aGVy d2lzZSkgZm9yIHJlc2VydmVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSUFO QSBNVVNUIE5PVCBpc3N1ZSBhbnkgUk9BcyAoQVMwIG9yIG90aGVyd2lzZSkgZm9yIHJlc2VydmVk PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHJlc291cmNlcyB0aGF0IGFyZSBleHBlY3RlZCB0byBiZSBnbG9iYWxseSByb3V0ZWQuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVzb3VyY2VzIHRoYXQgYXJlIGV4cGVjdGVk IHRvIGJlIGdsb2JhbGx5IHJvdXRlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjYuICBV bmFsbG9jYXRlZCBSZXNvdXJjZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij42LiAg VW5hbGxvY2F0ZWQgUmVzb3VyY2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRl cm5ldCBOdW1iZXIgUmVzb3VyY2VzIHRoYXQgaGF2ZSBub3QgeWV0IGJlZW4gYWxsb2NhdGVkIGZv cjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0IE51bWJlciBSZXNv dXJjZXMgdGhhdCBoYXZlIG5vdCB5ZXQgYmVlbiBhbGxvY2F0ZWQgZm9yPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNwZWNpYWwgcHVycG9z ZXMgW1JGQzU3MzZdLCB0byBSZWdpb25hbCBJbnRlcm5ldCBSZWdpc3RyaWVzIChSSVJzKSw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzcGVjaWFsIHB1cnBvc2VzIFtSRkM1NzM2 XSwgdG8gUmVnaW9uYWwgSW50ZXJuZXQgUmVnaXN0cmllcyAoUklScyksPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9yIHRvIG90aGVycyBh cmUgY29uc2lkZXJlZCBhcyBub3QgaW50ZW5kZWQgdG8gYmUgZ2xvYmFsbHkgcm91dGVkLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9yIHRvIG90aGVycyBhcmUgY29uc2lkZXJl ZCBhcyBub3QgaW50ZW5kZWQgdG8gYmUgZ2xvYmFsbHkgcm91dGVkLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9 InBhcnQtbDUiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdl IDEwLCBsaW5lIDI4PC9lbT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yNSIgLz48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTAsIGxpbmUgMjg8 L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgMjI0LjEuMC4wLTIy NC4xLjI1NS4yNTUgKDIyNC4xLzE2KTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgICAgICAgICAgMjI0LjEuMC4wLTIyNC4xLjI1NS4yNTUgKDIyNC4xLzE2KTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgIC0g UkVTRVJWRUQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgIC0gUkVT RVJWRUQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgICAgICAgICAyMjQuNS4wLjAtMjI0LjI1MS4yNTUuMjU1ICgyNTEgLzE2cyk8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIDIyNC41LjAuMC0yMjQu MjUxLjI1NS4yNTUgKDI1MSAvMTZzKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIDIyNS4wLjAuMC0yMzEuMjU1LjI1NS4y NTUgKDcgLzhzKTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg MjI1LjAuMC4wLTIzMS4yNTUuMjU1LjI1NSAoNyAvOHMpPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBJUHY2OjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElQdjY6PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICAgICAgLSBOb2RlLUxvY2FsIFNjb3BlIE11bHRpY2FzdCBBZGRyZXNzZXM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgIC0gTm9kZS1Mb2NhbCBTY29wZSBNdWx0aWNh c3QgQWRkcmVzc2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgLSBMaW5rLUxvY2FsIFNjb3BlIE11bHRpY2FzdCBBZGRyZXNz ZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgIC0gTGluay1Mb2Nh bCBTY29wZSBNdWx0aWNhc3QgQWRkcmVzc2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBJQU5BIE1VU1QgTk9UIGlzc3VlIGFueSBST0FzIChBUzAgb3Igb3RoZXJ3aXNlKSBmb3IgYW55 IG90aGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSUFOQSBNVVNUIE5PVCBp c3N1ZSBhbnkgUk9BcyAoQVMwIG9yIG90aGVyd2lzZSkgZm9yIGFueSBvdGhlcjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFt ZT0iZGlmZjAwMDgiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBtdWx0aWNhc3QgYWRkcmVzc2Vz IHVubGVzcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5kaXJlY3RlZC48L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG11bHRpY2FzdCBhZGRyZXNzZXMgdW5sZXNzIDxzcGFu IGNsYXNzPSJpbnNlcnQiPmRpcmVjdGVkIGJ5IGFuIElFU0cgYXBwcm92ZWQgc3RhbmRhcmRzPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICB0cmFjayBkb2N1bWVudCB3aXRoIGFuIGFwcHJvcHJpYXRlIElBTkEgQ29uc2lkZXJhdGlv bnMgc2VjdGlvbi48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij45LiAgSW5mb3Jt YXRpb25hbCBPYmplY3RzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+OS4gIEluZm9y bWF0aW9uYWwgT2JqZWN0czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgT25lIGluZm9y bWF0aW9uYWwgb2JqZWN0IHRoYXQgY2FuIGV4aXN0IGF0IGEgcHVibGljYXRpb24gcG9pbnQgb2Yg YW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBPbmUgaW5mb3JtYXRpb25hbCBv YmplY3QgdGhhdCBjYW4gZXhpc3QgYXQgYSBwdWJsaWNhdGlvbiBwb2ludCBvZiBhbjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBSUEtJIHJl cG9zaXRvcnkgaXMgdGhlIEdob3N0YnVzdGVycyBSZWNvcmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBSUEtJIHJlcG9zaXRvcnkgaXMgdGhlIEdob3N0YnVzdGVycyBSZWNvcmQ8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg W0ktRC5pZXRmLXNpZHItZ2hvc3RidXN0ZXJzXS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBbSS1ELmlldGYtc2lkci1naG9zdGJ1c3RlcnNdLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgSUFOQSBNVVNUIGlzc3VlIGEgZ2hvc3RidXN0ZXJzIG9iamVjdCBhcHByb3By aWF0ZSBpbiBjb250ZW50IGZvciB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBJQU5BIE1VU1QgaXNzdWUgYSBnaG9zdGJ1c3RlcnMgb2JqZWN0IGFwcHJvcHJpYXRlIGluIGNv bnRlbnQgZm9yIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICByZXNvdXJjZXMgSUFOQSBtYWludGFpbnMuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgcmVzb3VyY2VzIElBTkEgbWFpbnRhaW5zLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxhIG5h bWU9InBhcnQtbDYiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBw YWdlIDE2LCBsaW5lIDExPC9lbT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yNiIg Lz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTYsIGxpbmUg MTE8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBUaGUgYXV0aG9ycyBhY2tub3dsZWRnZSBEYXZlIE1leWVyIGZvciBoZWxwZnVs IGRpcmVjdGlvbiB3aXRoIHJlZ2FyZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFRoZSBhdXRob3JzIGFja25vd2xlZGdlIERhdmUgTWV5ZXIgZm9yIGhlbHBmdWwgZGlyZWN0aW9u IHdpdGggcmVnYXJkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHRvIG11bHRpY2FzdCBhc3NpZ25tZW50cy48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB0byBtdWx0aWNhc3QgYXNzaWdubWVudHMuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4xNC4gIFJlZmVyZW5jZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4xNC4gIFJlZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjE0LjEuICBO b3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjE0LjEu ICBOb3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0kt RC5pZXRmLXNpZHItYXJjaF08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbSS1E LmlldGYtc2lkci1hcmNoXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIExlcGluc2tpLCBNLiBhbmQgUy4gS2VudCwgIkFu IEluZnJhc3RydWN0dXJlIHRvIFN1cHBvcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICAgICAgIExlcGluc2tpLCBNLiBhbmQgUy4gS2VudCwgIkFuIEluZnJhc3RydWN0 dXJlIHRvIFN1cHBvcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA5IiAvPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgICAgICAgICAgICBTZWN1cmUgSW50ZXJuZXQgUm91dGluZyIsIDxzcGFuIGNsYXNzPSJk ZWxldGUiPmRyYWZ0LWlldGYtc2lkci1hcmNoLTExPC9zcGFuPiAod29yayBpbjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIFNlY3VyZSBJbnRlcm5ldCBSb3V0 aW5nIiwgPHNwYW4gY2xhc3M9Imluc2VydCI+ZHJhZnQtaWV0Zi1zaWRyLWFyY2gtMTI8L3NwYW4+ ICh3b3JrIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgICAgICAgICBwcm9ncmVzcyksIDxzcGFuIGNsYXNzPSJkZWxldGUiPlNl cHRlbWJlciAyMDEwLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICAgICAgICAgICBwcm9ncmVzcyksIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkZlYnJ1YXJ5IDIwMTEu PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0ktRC5pZXRmLXNpZHItY3Bd PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW0ktRC5pZXRmLXNpZHItY3BdPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICAgICAgICAgS2VudCwgUy4sIEtvbmcsIEQuLCBTZW8sIEsuLCBhbmQgUi4gV2F0cm8sICJDZXJ0 aWZpY2F0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgS2Vu dCwgUy4sIEtvbmcsIEQuLCBTZW8sIEsuLCBhbmQgUi4gV2F0cm8sICJDZXJ0aWZpY2F0ZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg ICAgICAgIFBvbGljeSAoQ1ApIGZvciB0aGUgUmVzb3VyY2UgUEtJIChSUEtJIiw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIFBvbGljeSAoQ1ApIGZvciB0aGUg UmVzb3VyY2UgUEtJIChSUEtJIiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBkcmFmdC1pZXRmLXNpZHItY3AtMTYgKHdv cmsgaW4gcHJvZ3Jlc3MpLCBEZWNlbWJlciAyMDEwLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1zaWRyLWNwLTE2ICh3b3JrIGluIHByb2dy ZXNzKSwgRGVjZW1iZXIgMjAxMC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtJLUQu aWV0Zi1zaWRyLWdob3N0YnVzdGVyc108L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBbSS1ELmlldGYtc2lkci1naG9zdGJ1c3RlcnNdPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgQnVzaCwgUi4sICJUaGUg UlBLSSBHaG9zdGJ1c3RlcnMgUmVjb3JkIiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICAgICAgIEJ1c2gsIFIuLCAiVGhlIFJQS0kgR2hvc3RidXN0ZXJzIFJlY29yZCIs PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZD48YSBuYW1lPSJkaWZmMDAxMCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAg ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZHJhZnQtaWV0Zi1zaWRyLWdob3N0YnVzdGVycy0wMDwv c3Bhbj4gKHdvcmsgaW4gcHJvZ3Jlc3MpLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRyYWZ0LWlldGYtc2lkci1naG9z dGJ1c3RlcnMtMDM8L3NwYW4+ICh3b3JrIGluIHByb2dyZXNzKSw8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPkRlY2VtYmVyIDIwMTAuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPk1hcmNoIDIw MTEuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0ktRC5pZXRmLXNpZHIt cmVzLWNlcnRzXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtJLUQuaWV0Zi1z aWRyLXJlcy1jZXJ0c108L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBIdXN0b24sIEcuLCBNaWNoYWVsc29uLCBHLiwgYW5k IFIuIExvb21hbnMsICJBIFByb2ZpbGUgZm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgICBIdXN0b24sIEcuLCBNaWNoYWVsc29uLCBHLiwgYW5kIFIuIExvb21h bnMsICJBIFByb2ZpbGUgZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgWC41MDkgUEtJWCBSZXNvdXJjZSBDZXJ0aWZp Y2F0ZXMiLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgWC41 MDkgUEtJWCBSZXNvdXJjZSBDZXJ0aWZpY2F0ZXMiLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIGRyYWZ0LWlldGYtc2lk ci1yZXMtY2VydHMtMjEgKHdvcmsgaW4gcHJvZ3Jlc3MpLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1zaWRyLXJlcy1jZXJ0cy0yMSAod29y ayBpbiBwcm9ncmVzcyksPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxMC48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIERlY2VtYmVyIDIwMTAuPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBbSS1ELmlldGYtc2lkci1yb2EtZm9ybWF0XTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtJLUQuaWV0Zi1zaWRyLXJvYS1mb3JtYXRdPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAg ICAgICAgTGVwaW5za2ksIE0uLCBLZW50LCBTLiwgYW5kIEQuIEtvbmcsICJBIFByb2ZpbGUgZm9y IFJvdXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBMZXBp bnNraSwgTS4sIEtlbnQsIFMuLCBhbmQgRC4gS29uZywgIkEgUHJvZmlsZSBmb3IgUm91dGU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICBPcmlnaW4gQXV0aG9yaXphdGlvbnMgKFJPQXMpIiw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIE9yaWdpbiBBdXRob3JpemF0aW9ucyAoUk9Bcyki LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTEiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAg ICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPmRyYWZ0LWlldGYtc2lkci1yb2EtZm9ybWF0LTA5PC9z cGFuPiAod29yayBpbiBwcm9ncmVzcyksPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ZHJhZnQtaWV0Zi1zaWRyLXJvYS1m b3JtYXQtMTA8L3NwYW4+ICh3b3JrIGluIHByb2dyZXNzKSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPk5vdmVtYmVyIDIwMTAuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkZlYnJ1YXJ5IDIw MTEuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0ktRC5pZXRmLXNpZHIt cm9hLXZhbGlkYXRpb25dPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW0ktRC5p ZXRmLXNpZHItcm9hLXZhbGlkYXRpb25dPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgSHVzdG9uLCBHLiBhbmQgRy4gTWlj aGFlbHNvbiwgIlZhbGlkYXRpb24gb2YgUm91dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgICAgIEh1c3RvbiwgRy4gYW5kIEcuIE1pY2hhZWxzb24sICJWYWxpZGF0 aW9uIG9mIFJvdXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgICAgT3JpZ2luYXRpb24gdXNpbmcgdGhlIFJlc291cmNlIENl cnRpZmljYXRlIFBLSSBhbmQgUk9BcyIsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgICAgICBPcmlnaW5hdGlvbiB1c2luZyB0aGUgUmVzb3VyY2UgQ2VydGlmaWNhdGUg UEtJIGFuZCBST0FzIiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBkcmFmdC1pZXRmLXNpZHItcm9hLXZhbGlkYXRpb24t MTAgKHdvcmsgaW4gcHJvZ3Jlc3MpLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgICAgICAgICAgZHJhZnQtaWV0Zi1zaWRyLXJvYS12YWxpZGF0aW9uLTEwICh3b3JrIGluIHBy b2dyZXNzKSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDEwLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMC48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFtJLUQuaWV0Zi1zaWRyLXJwa2ktbWFuaWZlc3RzXTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtJLUQuaWV0Zi1zaWRyLXJwa2ktbWFuaWZlc3RzXTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg ICAgICAgIEF1c3RlaW4sIFIuLCBIdXN0b24sIEcuLCBLZW50LCBTLiwgYW5kIE0uIExlcGluc2tp LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgQXVzdGVpbiwg Ui4sIEh1c3RvbiwgRy4sIEtlbnQsIFMuLCBhbmQgTS4gTGVwaW5za2ksPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgIk1h bmlmZXN0cyBmb3IgdGhlIFJlc291cmNlIFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUiLDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgIk1hbmlmZXN0cyBmb3Ig dGhlIFJlc291cmNlIFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUiLDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIGRyYWZ0 LWlldGYtc2lkci1ycGtpLW1hbmlmZXN0cy0wOSAod29yayBpbiBwcm9ncmVzcyksPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBkcmFmdC1pZXRmLXNpZHItcnBr aS1tYW5pZmVzdHMtMDkgKHdvcmsgaW4gcHJvZ3Jlc3MpLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIE5vdmVtYmVyIDIw MTAuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBOb3ZlbWJl ciAyMDEwLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYw MDEyIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjE0LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIFtJLUQuaWV0Zi1zaWRyLWx0YW1nbXRdPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIEtlbnQs IFMuIGFuZCBNLiBSZXlub2xkcywgIkxvY2FsIFRydXN0IEFuY2hvciBNYW5hZ2VtZW50PC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICAgICAgICAgICAgIGZvciB0aGUgUmVzb3VyY2UgUHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSIs PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICAgICAgICAgICAgIGRyYWZ0LWlldGYtc2lkci1sdGFtZ210LTAwICh3b3JrIGluIHBy b2dyZXNzKSw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMC48L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgW0kt RC5pZXRmLXNpZHItdXNlY2FzZXNdPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIE1hbmRlcnNvbiwgVC4sIFNy aXJhbSwgSy4sIGFuZCBSLiBXaGl0ZSwgIlVzZSBDYXNlcyBhbmQ8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAg aW50ZXJwcmV0YXRpb24gb2YgUlBLSSBvYmplY3RzIGZvciBpc3N1ZXJzIGFuZCByZWx5aW5nPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICAgICAgICAgICAgIHBhcnRpZXMiLCBkcmFmdC1pZXRmLXNpZHItdXNlY2FzZXMtMDEgKHdv cmsgaW4gcHJvZ3Jlc3MpLDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICBEZWNlbWJlciAyMDEwLjwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICBbUkZDMDc5MV0gIFBvc3RlbCwgSi4sICJJbnRlcm5ldCBQcm90b2NvbCIsIFNURCA1LCBS RkMgNzkxLDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgICAgICAgICAgICBTZXB0ZW1iZXIgMTk4MS48L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgW1JG QzA5MTldICBNb2d1bCwgSi4sICJCcm9hZGNhc3RpbmcgSW50ZXJuZXQgRGF0YWdyYW1zIiwgU1RE IDUsPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICAgICAgICAgICAgIFJGQyA5MTksIE9jdG9iZXIgMTk4NC48L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg W1JGQzA5MjJdICBNb2d1bCwgSi4sICJCcm9hZGNhc3RpbmcgSW50ZXJuZXQgZGF0YWdyYW1zIGlu IHRoZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgICAgICAgICAgICBwcmVzZW5jZSBvZiBzdWJuZXRzIiwgU1REIDUsIFJGQyA5 MjIsIE9jdG9iZXIgMTk4NC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgW1JGQzExMTJdICBEZWVyaW5nLCBTLiwgIkhv c3QgZXh0ZW5zaW9ucyBmb3IgSVAgbXVsdGljYXN0aW5nIiwgU1REIDUsPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAg ICAgIFJGQyAxMTEyLCBBdWd1c3QgMTk4OS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgW1JGQzExMjJdICBCcmFkZW4s IFIuLCAiUmVxdWlyZW1lbnRzIGZvciBJbnRlcm5ldCBIb3N0cyAtPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAg IENvbW11bmljYXRpb24gTGF5ZXJzIiwgU1REIDMsIFJGQyAxMTIyLCBPY3RvYmVyIDE5ODkuPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtS RkMxOTE4XSAgUmVraHRlciwgWS4sIE1vc2tvd2l0eiwgUi4sIEthcnJlbmJlcmcsIEQuLCBHcm9v dCwgRy4sIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkMxOTE4XSAg UmVraHRlciwgWS4sIE1vc2tvd2l0eiwgUi4sIEthcnJlbmJlcmcsIEQuLCBHcm9vdCwgRy4sIGFu ZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgIEUuIExlYXIsICJBZGRyZXNzIEFsbG9jYXRpb24gZm9yIFByaXZhdGUgSW50 ZXJuZXRzIiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIEUu IExlYXIsICJBZGRyZXNzIEFsbG9jYXRpb24gZm9yIFByaXZhdGUgSW50ZXJuZXRzIiw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICBCQ1AgNSwgUkZDIDE5MTgsIEZlYnJ1YXJ5IDE5OTYuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgICAgICBCQ1AgNSwgUkZDIDE5MTgsIEZlYnJ1YXJ5IDE5OTYu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAi S2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVz ZSBpbiBSRkNzIHRvIEluZGljYXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQ IDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1h cmNoIDE5OTcuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlm ZjAwMTMiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+W1JGQzI0NjBdICBEZWVyaW5nLCBTLiBhbmQg Ui4gSGluZGVuLCAiSW50ZXJuZXQgUHJvdG9jb2wsIFZlcnNpb24gNjwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAg ICAoSVB2NikgU3BlY2lmaWNhdGlvbiIsIFJGQyAyNDYwLCBEZWNlbWJlciAxOTk4Ljwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICBbUkZDMjU0NF0gIEJyYWRuZXIsIFMuIGFuZCBKLiBNY1F1YWlkLCAiQmVuY2htYXJraW5n IE1ldGhvZG9sb2d5IGZvcjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICBOZXR3b3JrIEludGVyY29ubmVjdCBE ZXZpY2VzIiwgUkZDIDI1NDQsIE1hcmNoIDE5OTkuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkMyODYwXSAgQ2FycGVudGVyLCBCLiwg QmFrZXIsIEYuLCBhbmQgTS4gUm9iZXJ0cywgIk1lbW9yYW5kdW0gb2Y8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDMjg2MF0gIENhcnBlbnRlciwgQi4sIEJha2VyLCBGLiwg YW5kIE0uIFJvYmVydHMsICJNZW1vcmFuZHVtIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgVW5kZXJzdGFuZGluZyBD b25jZXJuaW5nIHRoZSBUZWNobmljYWwgV29yayBvZiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgICAgICAgIFVuZGVyc3RhbmRpbmcgQ29uY2VybmluZyB0aGUgVGVj aG5pY2FsIFdvcmsgb2YgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgSW50ZXJuZXQgQXNzaWduZWQgTnVtYmVycyBB dXRob3JpdHkiLCBSRkMgMjg2MCwgSnVuZSAyMDAwLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICAgICAgICAgSW50ZXJuZXQgQXNzaWduZWQgTnVtYmVycyBBdXRob3JpdHki LCBSRkMgMjg2MCwgSnVuZSAyMDAwLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JG QzMwNjhdICBIdWl0ZW1hLCBDLiwgIkFuIEFueWNhc3QgUHJlZml4IGZvciA2dG80IFJlbGF5IFJv dXRlcnMiLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkMzMDY4XSAgSHVp dGVtYSwgQy4sICJBbiBBbnljYXN0IFByZWZpeCBmb3IgNnRvNCBSZWxheSBSb3V0ZXJzIiw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICBSRkMgMzA2OCwgSnVuZSAyMDAxLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICAgICAgICAgUkZDIDMwNjgsIEp1bmUgMjAwMS48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFtSRkMzNzc5XSAgTHlubiwgQy4sIEtlbnQsIFMuLCBhbmQgSy4gU2VvLCAi WC41MDkgRXh0ZW5zaW9ucyBmb3IgSVA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBbUkZDMzc3OV0gIEx5bm4sIEMuLCBLZW50LCBTLiwgYW5kIEsuIFNlbywgIlguNTA5IEV4dGVu c2lvbnMgZm9yIElQPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgICAgQWRkcmVzc2VzIGFuZCBBUyBJZGVudGlmaWVycyIsIFJG QyAzNzc5LCBKdW5lIDIwMDQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgICAgICBBZGRyZXNzZXMgYW5kIEFTIElkZW50aWZpZXJzIiwgUkZDIDM3NzksIEp1bmUgMjAw NC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkMzODQ5XSAgSHVzdG9uLCBHLiwg TG9yZCwgQS4sIGFuZCBQLiBTbWl0aCwgIklQdjYgQWRkcmVzcyBQcmVmaXg8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDMzg0OV0gIEh1c3RvbiwgRy4sIExvcmQsIEEuLCBh bmQgUC4gU21pdGgsICJJUHY2IEFkZHJlc3MgUHJlZml4PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgUmVzZXJ2ZWQgZm9y IERvY3VtZW50YXRpb24iLCBSRkMgMzg0OSwgSnVseSAyMDA0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgUmVzZXJ2ZWQgZm9yIERvY3VtZW50YXRpb24iLCBS RkMgMzg0OSwgSnVseSAyMDA0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxh IG5hbWU9ImRpZmYwMDE0IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPltSRkMzODc5XSAgSHVpdGVt YSwgQy4gYW5kIEIuIENhcnBlbnRlciwgIkRlcHJlY2F0aW5nIFNpdGUgTG9jYWw8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAg ICAgICAgICAgQWRkcmVzc2VzIiwgUkZDIDM4NzksIFNlcHRlbWJlciAyMDA0Ljwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICBbUkZDMzkyN10gIENoZXNoaXJlLCBTLiwgQWJvYmEsIEIuLCBhbmQgRS4gR3V0dG1hbiwgIkR5 bmFtaWM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgICAgICAgICAgICAgQ29uZmlndXJhdGlvbiBvZiBJUHY0IExpbmstTG9jYWwg QWRkcmVzc2VzIiwgUkZDIDM5MjcsPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIE1heSAyMDA1Ljwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDNDI3 MV0gIFJla2h0ZXIsIFkuLCBMaSwgVC4sIGFuZCBTLiBIYXJlcywgIkEgQm9yZGVyIEdhdGV3YXk8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDNDI3MV0gIFJla2h0ZXIsIFku LCBMaSwgVC4sIGFuZCBTLiBIYXJlcywgIkEgQm9yZGVyIEdhdGV3YXk8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBQcm90 b2NvbCA0IChCR1AtNCkiLCBSRkMgNDI3MSwgSmFudWFyeSAyMDA2LjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgUHJvdG9jb2wgNCAoQkdQLTQpIiwgUkZDIDQy NzEsIEphbnVhcnkgMjAwNi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkM0Mjkx XSAgSGluZGVuLCBSLiBhbmQgUy4gRGVlcmluZywgIklQIFZlcnNpb24gNiBBZGRyZXNzaW5nPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzQyOTFdICBIaW5kZW4sIFIuIGFu ZCBTLiBEZWVyaW5nLCAiSVAgVmVyc2lvbiA2IEFkZHJlc3Npbmc8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBBcmNoaXRl Y3R1cmUiLCBSRkMgNDI5MSwgRmVicnVhcnkgMjAwNi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICAgICAgIEFyY2hpdGVjdHVyZSIsIFJGQyA0MjkxLCBGZWJydWFyeSAy MDA2LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzQzODBdICBIdWl0ZW1hLCBD LiwgIlRlcmVkbzogVHVubmVsaW5nIElQdjYgb3ZlciBVRFAgdGhyb3VnaDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkM0MzgwXSAgSHVpdGVtYSwgQy4sICJUZXJlZG86IFR1 bm5lbGluZyBJUHY2IG92ZXIgVURQIHRocm91Z2g8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBOZXR3b3JrIEFkZHJlc3Mg VHJhbnNsYXRpb25zIChOQVRzKSIsIFJGQyA0MzgwLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICAgICAgICAgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0aW9ucyAoTkFUcyki LCBSRkMgNDM4MCw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICAgICAgICAgICBGZWJydWFyeSAyMDA2LjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgRmVicnVhcnkgMjAwNi48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNSIgLz48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5bUkZDNDg0M10gIE5pa2FuZGVyLCBQLiwgTGFnYW5pZXIsIEouLCBhbmQgRi4gRHVwb250 LCAiQW4gSVB2NiBQcmVmaXg8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgZm9yIE92ZXJsYXkgUm91dGFibGUg Q3J5cHRvZ3JhcGhpYyBIYXNoIElkZW50aWZpZXJzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIChPUkNISUQp IiwgUkZDIDQ4NDMsIEFwcmlsIDIwMDcuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkM1MTgwXSAgUG9wb3ZpY2l1LCBDLiwgSGFtemEs IEEuLCBWYW4gZGUgVmVsZGUsIEcuLCBhbmQgRC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBbUkZDNTE4MF0gIFBvcG92aWNpdSwgQy4sIEhhbXphLCBBLiwgVmFuIGRlIFZlbGRl LCBHLiwgYW5kIEQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgICAgRHVnYXRraW4sICJJUHY2IEJlbmNobWFya2luZyBNZXRo b2RvbG9neSBmb3IgTmV0d29yazwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgICAgICAgRHVnYXRraW4sICJJUHY2IEJlbmNobWFya2luZyBNZXRob2RvbG9neSBmb3IgTmV0 d29yazwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgICAgICAgIEludGVyY29ubmVjdCBEZXZpY2VzIiwgUkZDIDUxODAsIE1heSAyMDA4 LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgSW50ZXJjb25u ZWN0IERldmljZXMiLCBSRkMgNTE4MCwgTWF5IDIwMDguPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBbUkZDNTczNV0gIENvdHRvbiwgTS4gYW5kIEwuIFZlZ29kYSwgIlNwZWNpYWwgVXNl IElQdjQgQWRkcmVzc2VzIiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZD NTczNV0gIENvdHRvbiwgTS4gYW5kIEwuIFZlZ29kYSwgIlNwZWNpYWwgVXNlIElQdjQgQWRkcmVz c2VzIiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgICAgICAgICBCQ1AgMTUzLCBSRkMgNTczNSwgSmFudWFyeSAyMDEwLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgQkNQIDE1MywgUkZDIDU3MzUs IEphbnVhcnkgMjAxMC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkM1NzM2XSAg SHVzdG9uLCBHLiwgQ290dG9uLCBNLiwgYW5kIEwuIFZlZ29kYSwgIklBTkEgSVB2NCBTcGVjaWFs PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzU3MzZdICBIdXN0b24sIEcu LCBDb3R0b24sIE0uLCBhbmQgTC4gVmVnb2RhLCAiSUFOQSBJUHY0IFNwZWNpYWw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAg ICBQdXJwb3NlIEFkZHJlc3MgUmVnaXN0cnkiLCBSRkMgNTczNiwgSmFudWFyeSAyMDEwLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgUHVycG9zZSBBZGRyZXNz IFJlZ2lzdHJ5IiwgUkZDIDU3MzYsIEphbnVhcnkgMjAxMC48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5b UkZDNTczN10gIEFya2tvLCBKLiwgQ290dG9uLCBNLiwgYW5kIEwuIFZlZ29kYSwgIklQdjQgQWRk cmVzcyBCbG9ja3M8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgUmVzZXJ2ZWQgZm9yIERvY3VtZW50YXRpb24i LCBSRkMgNTczNywgSmFudWFyeSAyMDEwLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDNTc3MV0gIENvdHRvbiwgTS4sIFZlZ29kYSwg TC4sIGFuZCBELiBNZXllciwgIklBTkEgR3VpZGVsaW5lcyBmb3I8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBbUkZDNTc3MV0gIENvdHRvbiwgTS4sIFZlZ29kYSwgTC4sIGFuZCBE LiBNZXllciwgIklBTkEgR3VpZGVsaW5lcyBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBJUHY0IE11bHRpY2FzdCBB ZGRyZXNzIEFzc2lnbm1lbnRzIiwgQkNQIDUxLCBSRkMgNTc3MSw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIElQdjQgTXVsdGljYXN0IEFkZHJlc3MgQXNzaWdu bWVudHMiLCBCQ1AgNTEsIFJGQyA1NzcxLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIE1hcmNoIDIwMTAuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBNYXJjaCAyMDEwLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDE3IiAvPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTQuMi4gIEluZm9ybWF0aXZlIFJlZmVy ZW5jZTwvc3Bhbj5zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPkFwcGVuZGl4IEEuICBJQU5BIFJlc2VydmVkIElQdjQgQWRkcmVzcyBCbG9jazwv c3Bhbj5zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAw MTgiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5bSS1ELmll dGYtc2lkci1sdGFtZ210XTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+VGhpcyBsaXN0IG9mIEFkZHJlc3MgU3BhY2U8L3NwYW4+ IGFuZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5SRkNzIHdhcyBjb3JyZWN0IGF0PC9zcGFuPiB0aGUg PHNwYW4gY2xhc3M9Imluc2VydCI+dGltZSBvZjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4g ICAgICAgICAgICAgIEtlbnQsIFMuPC9zcGFuPiBhbmQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TS4g UmV5bm9sZHMsICJMb2NhbCBUcnVzdCBBbmNob3IgTWFuYWdlbWVudDwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgd3JpdGluZzwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICAgICAgICAgIGZvcjwvc3Bhbj4gdGhlIDxz cGFuIGNsYXNzPSJkZWxldGUiPlJlc291cmNlIFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUiLDwv c3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0 ZSI+ICAgICAgICAgICAgICBkcmFmdC1pZXRmLXNpZHItbHRhbWdtdC0wMCAod29yayBpbiBwcm9n cmVzcyksPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFz cz0iZGVsZXRlIj4gICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTAuPC9zcGFuPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZD48YSBuYW1lPSJkaWZmMDAxOSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNz PSJkZWxldGUiPltJLUQuaWV0Zi1zaWRyLXVzZWNhc2VzXTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPklQdjQgQWRkcmVzcyBC bG9ja3M8L3NwYW4+IGFuZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50aGUgUkZDcyB3aGljaCBkaXJl Y3QgSUFOQSB0byBSZXNlcnZlIHRoZW08L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAg ICAgICAgICBNYW5kZXJzb24sIFQuLCBTcmlyYW0sIEsuLDwvc3Bhbj4gYW5kIDxzcGFuIGNsYXNz PSJkZWxldGUiPlIuIFdoaXRlLCAiVXNlIENhc2VzIGFuZDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAgICBpbnRl cnByZXRhdGlvbiBvZiBSUEtJIG9iamVjdHMgZm9yIGlzc3VlcnMgYW5kIHJlbHlpbmc8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAg ICAgICAgICAgICAgcGFydGllcyIsIGRyYWZ0LWlldGYtc2lkci11c2VjYXNlcy0wMSAod29yayBp biBwcm9ncmVzcyksPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gICAgICAgICAgICAgIERlY2VtYmVyIDIwMTAuPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyMCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPltSRkMwNzkxXSAgUG9zdGVsLCBKLiwgIkludGVybmV0IFByb3RvY29s IiwgU1REIDUsPC9zcGFuPiBSRkMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NzkxLDwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Ky0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0rPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAgICAgU2VwdGVt YmVyIDE5ODEuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICB8ICAgICAgIFByZWZpeCAgICAgICB8PC9zcGFuPiAgICAgICAgICAg ICAgICAgUkZDICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnwgICBUQlIgICB8 PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICArLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLSs8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwgICAgICAwLjAuMC4wLzggICAgIHwgICAgICBS RkMxMTIyLCBTZWN0aW9uIDMuMi4xLjMgICAgICB8ICAgIE5vICAgfDwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgfCAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICB8ICAgICAxMC4wLjAuMC84ICAgICB8ICAgICAgICAgICAgICAgUkZDMTkxOCAg ICAgICAgICAgICAgfCAgICBObyAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfDwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgfCAgICAg MTI3LjAuMC4wLzggICAgfCAgICAgIFJGQzExMjIsIFNlY3Rpb24gMy4yLjEuMyAgICAgIHwgICAg Tm8gICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICB8ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwgICAxNjkuMjU0LjAuMC8xNiAgIHwg ICAgICAgICAgICAgICBSRkMzOTI3ICAgICAgICAgICAgICB8ICAgIE5vICAgfDwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgfCAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICB8ICAgIDE3Mi4xNi4wLjAvMTIgICB8ICAgICAgICAgICAgICAgUkZD MTkxOCAgICAgICAgICAgICAgfCAgICBObyAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfDwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg fCAgICAxOTIuMC4wLjAvMjQgICAgfCAgICAgICAgICAgICAgIFJGQzU3MzYgICAgICAgICAgICAg IHwgVmFyaW91cyB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICB8ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwgICAgMTkyLjAuMi4wLzI0 ICAgIHwgICAgICAgICAgICAgICBSRkM1NzM3ICAgICAgICAgICAgICB8ICAgIE5vICAgfDwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ ICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB8ICAgMTkyLjg4Ljk5LjAvMjQgICB8ICAgICAgICAgICAg ICAgUkZDMzA2OCAgICAgICAgICAgICAgfCAgIFllcyAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfDwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgfCAgIDE5Mi4xNjguMC4wLzE2ICAgfCAgICAgICAgICAgICAgIFJGQzE5MTggICAgICAg ICAgICAgIHwgICAgTm8gICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB8ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgIHw8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwgICAgMTk4LjE4 LjAuMC8xNSAgIHwgICAgICAgICAgICAgICBSRkMyNTQ0ICAgICAgICAgICAgICB8ICAgIE5vICAg fDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB8ICAgMTk4LjUxLjEwMC4wLzI0ICB8ICAgICAg ICAgICAgICAgUkZDNTczNyAgICAgICAgICAgICAgfCAgICBObyAgIHw8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgfCAgIDIwMy4wLjExMy4wLzI0ICAgfCAgICAgICAgICAgICAgIFJGQzU3Mzcg ICAgICAgICAgICAgIHwgICAgTm8gICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB8ICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgIHw8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwgICAg IDIyNC4wLjAuMC80ICAgIHwgICAgICAgICAgICAgICBSRkM1NzcxICAgICAgICAgICAgICB8ICAg IE5vICAgfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB8ICAgICAyNDAuMC4wLjAvNCAgICB8 ICAgICAgICAgUkZDMTExMiwgU2VjdGlvbiA0ICAgICAgICAgfCAgICBObyAgIHw8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g Y2xhc3M9Imluc2VydCI+ICAgfCAyNTUuMjU1LjI1NS4yNTUvMzIgfCAgICBSRkM5MTksIFNlY3Rp b24gNyBhbmQgUkZDOTIyLCAgIHwgICAgTm8gICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB8ICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICBTZWN0aW9uIDcgICAgICAgICAgICAgfCAgICAgICAgIHw8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tKzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48 YSBuYW1lPSJkaWZmMDAyMSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJk ZWxldGUiPltSRkMyNDYwXSAgRGVlcmluZywgUy48L3NwYW4+IGFuZCA8c3BhbiBjbGFzcz0iZGVs ZXRlIj5SLiBIaW5kZW4sICJJbnRlcm5ldCBQcm90b2NvbCwgVmVyc2lvbiA2PC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UQlI6 IFRvIEJlIFJvdXRlZCwgdGhlIGludGVudGlvbiBvZiB0aGUgUkZDIHBlcnRhaW5pbmcgdG8gdGhl IGFkZHJlc3M8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAgICAoSVB2Nikg U3BlY2lmaWNhdGlvbiIsPC9zcGFuPiBSRkMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MjQ2MCwgRGVj ZW1iZXIgMTk5OC48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBibG9jay48 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRhYmxlIDE8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+QXBwZW5kaXggQi4gIElBTkEgUmVzZXJ2ZWQgSVB2NiBBZGRyZXNzIEJsb2Nrczwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICBUaGlzIGxpc3Qgb2YgQWRkcmVzcyBTcGFjZSBhbmQgUkZDcyB3YXMgY29ycmVjdCBhdCB0 aGUgdGltZSBvZjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g Y2xhc3M9Imluc2VydCI+ICAgd3JpdGluZzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgSVB2NiBBZGRyZXNzIEJsb2Nr czwvc3Bhbj4gYW5kIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoZSBSRkNzIHdoaWNoIGRpcmVjdCBJ QU5BIHRvIFJlc2VydmUgdGhlbTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLSs8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICAgfCAgICAg UHJlZml4ICAgICB8ICAgUkZDICAgfCBUQlIgfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0rPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAgIHwg ICAgMDAwMDo6LzggICAgfCBSRkM0MjkxIHwgIE5vIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAgICAg ICB8ICAgIDAxMDA6Oi84ICAgIHwgUkZDNDI5MSB8ICBObyB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgIHw8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAg ICAgICAgfCAgICAwMjAwOjovNyAgICB8IFJGQzQyOTEgfCAgTm8gfDwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICB8PC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAg ICAgICAgICAgIHwgICAgMDQwMDo6LzYgICAgfCBSRkM0MjkxIHwgIE5vIHw8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgfDwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAg ICAgICAgICAgICAgICB8ICAgIDA4MDA6Oi81ICAgIHwgUkZDNDI5MSB8ICBObyB8PC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgIHw8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg ICAgICAgICAgICAgICAgICAgfCAgICAxMDAwOjovNCAgICB8IFJGQzQyOTEgfCAgTm8gfDwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICB8PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICAgICAgICAgICAgICAgICAgIHwgICAgNDAwMDo6LzMgICAgfCBSRkM0MjkxIHwgIE5vIHw8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAg fDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgICAgICAgICAgICAgICAgICB8ICAgIDYwMDA6Oi8zICAgIHwgUkZDNDI5MSB8ICBO byB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgIHwg ICAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICAgfCAgICA4MDAwOjovMyAgICB8IFJGQzQyOTEg fCAgTm8gfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAg ICB8ICAgICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAgIHwgICAgQTAwMDo6LzMgICAgfCBSRkM0 MjkxIHwgIE5vIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8ICAg ICAgICAgfCAgICAgfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAgICAgICB8ICAgIEMwMDA6Oi8zICAgIHwg UkZDNDI5MSB8ICBObyB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg fCAgICAgICAgIHwgICAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICAgfCAgICBFMDAwOjovNCAg ICB8IFJGQzQyOTEgfCAgTm8gfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgIHwgICAgICAgICB8ICAgICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAgIHwgICAgRjAwMDo6 LzUgICAgfCBSRkM0MjkxIHwgIE5vIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICB8ICAgICAgICAgfCAgICAgfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAgICAgICB8ICAgIEY4 MDA6Oi82ICAgIHwgUkZDNDI5MSB8ICBObyB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgfCAgICAgICAgIHwgICAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAgICAgfCAg ICBGQzAwOjovNyAgICB8IFJGQzQxOTMgfCAgTm8gfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICB8PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAg IHwgICAgRkUwMDo6LzkgICAgfCBSRkM0MjkxIHwgIE5vIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgfDwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAg ICAgICB8ICAgIEZFODA6Oi8xMCAgIHwgUkZDNDI5MSB8ICBObyB8PC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgIHw8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAg ICAgICAgICAgfCAgICBGRUMwOjovMTAgICB8IFJGQzM4NzkgfCAgTm8gfDwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICB8PC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAg ICAgICAgICAgICAgIHwgICAgRkYwMDo6LzggICAgfCBSRkM0MjkxIHwgIE5vIHw8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgfDwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg ICAgICAgICAgICAgICAgICB8IDIwMDE6MDAwMjo6LzQ4IHwgUkZDNTE4MCB8ICBObyB8PC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgIHw8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgICAgICAgICAgICAgICAgICAgfCAgMjAwMToxMDo6LzI4ICB8IFJGQzQ4NDMgfCAgTm8gfDwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0r PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIFRCUjogVG8gQmUgUm91dGVkLCB0aGUgaW50ZW50aW9uIG9mIHRoZTwvc3Bh bj4gUkZDIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnBlcnRhaW5pbmcgdG8gdGhlIGFkZHJlc3M8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBibG9jay48L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRhYmxlIDI8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij5BdXRob3JzJyBBZGRyZXNzZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij5BdXRob3JzJyBBZGRyZXNzZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IFRlcnJ5IE1hbmRlcnNvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRlcnJ5 IE1hbmRlcnNvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBJQ0FOTjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElDQU5O PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBFbWFpbDogdGVycnkubWFuZGVyc29uQGlj YW5uLm9yZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEVtYWlsOiB0ZXJyeS5t YW5kZXJzb25AaWNhbm4ub3JnPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBMZW8gVmVn b2RhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTGVvIFZlZ29kYTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJQ0FOTjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElDQU5OPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KCiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48 L3RyPgogICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRl ciI+PGEgbmFtZT0iZW5kIj4mbmJzcDtFbmQgb2YgY2hhbmdlcy4gMjEgY2hhbmdlIGJsb2Nrcy4m bmJzcDs8L2E+PC90aD48L3RyPgogICAgIDx0ciBjbGFzcz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48 aT4zMCBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90aD48dGg+PGk+IDwvaT48L3RoPjx0 aD48aT4xNjkgbGluZXMgY2hhbmdlZCBvciBhZGRlZDwvaT48L3RoPjx0ZD48L3RkPjwvdHI+CiAg ICAgPHRyPjx0ZCBjb2xzcGFuPSI1IiBhbGlnbj0iY2VudGVyIiBjbGFzcz0ic21hbGwiPjxici8+ VGhpcyBodG1sIGRpZmYgd2FzIHByb2R1Y2VkIGJ5IHJmY2RpZmYgMS40MS4gVGhlIGxhdGVzdCB2 ZXJzaW9uIGlzIGF2YWlsYWJsZSBmcm9tIDxhIGhyZWY9Imh0dHA6Ly93d3cudG9vbHMuaWV0Zi5v cmcvdG9vbHMvcmZjZGlmZi8iID5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88 L2E+IDwvdGQ+PC90cj4KICAgPC90YWJsZT4KICAgPC9ib2R5PgogICA8L2h0bWw+Cg== --_002_C9C4ED27E33Fterrymandersonicannorg_-- From hannes@juniper.net Fri Apr 8 10:03:41 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9459E3A6943 for ; Fri, 8 Apr 2011 10:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lYoxt494a3a for ; Fri, 8 Apr 2011 10:03:40 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 5FDEF3A68D4 for ; Fri, 8 Apr 2011 10:03:33 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTZ9ATlUV2OYBIo/QCLC65cl7drzWCn5o@postini.com; Fri, 08 Apr 2011 10:05:22 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Fri, 8 Apr 2011 10:02:05 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id EFBE52F616; Fri, 8 Apr 2011 19:04:00 +0200 (CEST) Date: Fri, 8 Apr 2011 19:04:00 +0200 From: Hannes Gredler To: Pradosh Mohapatra Message-ID: <20110408170400.GC11350@juniper.net> References: <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 17:03:41 -0000 On Thu, Apr 07, 2011 at 09:20:05PM -0700, Pradosh Mohapatra wrote: | > We seem to be in a bit of a jam :( I don't think SIDR is going to be | > able to, by declaration, get opensource implementations of AO to | > appear. I don't see non-open-source implementations on the server side | > for tcp-md5 sadly either, but at least fbsd/obsd/linux have tcp-md5 | > support. | | We don't seem to be converging. I would suggest that we keep the status quo | and make ssh mandatory to implement. Other mechanisms may get prescribed | in future as & when they become commonly available. not sure if mandating a single transport is needed at all. since the pros and cons of the various transport protocols (TCP, TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not simply enumerating the choices and leave it to the operator's local security policy which one to deploy ? IMO you cannot dictate local security policy as they are different between operators. also if the level of containment is sufficiently enough (e.g. local-cache only reachable through vrf, not accessible through internet it is perfectly reasonable even to load your cache records using vanilla TCP.) From pmohapat@cisco.com Fri Apr 8 10:47:39 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3593A69E2 for ; Fri, 8 Apr 2011 10:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSF46RYUpQr1 for ; Fri, 8 Apr 2011 10:47:38 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8AB053A69D6 for ; Fri, 8 Apr 2011 10:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=836; q=dns/txt; s=iport; t=1302284964; x=1303494564; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=MmoX+w2LHiv6pVdsKCBaWO1zEiUDCva1hZO5osAXFoM=; b=BPDnC3Fg82R/1HlmRJTIU6r15gWU7hpiNy26vGJ7uJGo9fr1HTgeBixQ YXe3jCyvv3z/uJLUn9gcIysyWH5XMxZUK+ZQllo/puJJzy/f18AzXPIsg DAKGJD2wcgi5rq3Koc3Z5H7YNBsB4pEqdK4ICAOLRMNCELeXg9R9oJ16C M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL9Jn02rRDoI/2dsb2JhbACmFXeIept0nByFbQSFVYd5 X-IronPort-AV: E=Sophos;i="4.63,325,1299456000"; d="scan'208";a="292332462" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 08 Apr 2011 17:49:24 +0000 Received: from dhcp-171-71-139-171.cisco.com (dhcp-171-71-139-171.cisco.com [171.71.139.171]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p38HnOxa012021; Fri, 8 Apr 2011 17:49:24 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: <20110408170400.GC11350@juniper.net> Date: Fri, 8 Apr 2011 10:49:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4A88F7EC-12D4-4AAA-92BE-D6A8BEACF776@cisco.com> References: <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> <20110408170400.GC11350@juniper.net> To: Hannes Gredler X-Mailer: Apple Mail (2.1081) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 17:47:39 -0000 > not sure if mandating a single transport is needed at all. >=20 > since the pros and cons of the various transport protocols > (TCP, TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not simply > enumerating the choices and leave it to the operator's local security = policy > which one to deploy ? >=20 > IMO you cannot dictate local security policy as they are different = between > operators. also if the level of containment is sufficiently enough = (e.g. > local-cache only reachable through vrf, not accessible through = internet > it is perfectly reasonable even to load your cache records using = vanilla TCP.) I have no problem listing various transports. I thought there was a = suggestion to keep one of them mandatory to encourage better interoperability. That = makes some sense. - Pradosh= From christopher.morrow@gmail.com Fri Apr 8 10:53:20 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F403A69EF for ; Fri, 8 Apr 2011 10:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.395 X-Spam-Level: X-Spam-Status: No, score=-103.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8ZA5uzCyMjq for ; Fri, 8 Apr 2011 10:53:20 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 19C633A69D6 for ; Fri, 8 Apr 2011 10:53:19 -0700 (PDT) Received: by wwa36 with SMTP id 36so3193141wwa.13 for ; Fri, 08 Apr 2011 10:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EIgWCaePULeIr5YVR4ccyP/lPhe/EiWw2gyIT6fGYC4=; b=SxiUN72KVHoDxZnZKelYPOI0W2PbW1m0rPMswieqnKrYP4p1g4kjgP6uya83I18zgx ZatnSLp4rZW2z+dxUjtDtWOxfocbJiFoLBRvNgLPfzNt39KMNbGrPpU9te5i0hbUksqr S3Y5c27ojODDvYKTojqZw7KMFrLaOVCcyc3cg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=H7UtxLAsdP6cke48Jw7lsJmQxuoK+eZfzvH76RKORg2PCutZJXdMqAffz7/ird4qDz 09Oun2i9yzuSPJ6h9NnOO0Uw1Esua9CGHvzUD5/SJaczafg6eGJhoNo/E2vct+8Zidsb apPVFVM64w+oZPZFBgwKZ5sIwastjnWnWndW0= MIME-Version: 1.0 Received: by 10.216.167.65 with SMTP id h43mr6680wel.17.1302285304831; Fri, 08 Apr 2011 10:55:04 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.13.131 with HTTP; Fri, 8 Apr 2011 10:55:04 -0700 (PDT) In-Reply-To: <4A88F7EC-12D4-4AAA-92BE-D6A8BEACF776@cisco.com> References: <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> <20110408170400.GC11350@juniper.net> <4A88F7EC-12D4-4AAA-92BE-D6A8BEACF776@cisco.com> Date: Fri, 8 Apr 2011 13:55:04 -0400 X-Google-Sender-Auth: 5zCQNAhOylSKqt1ATmEuO3MpUwU Message-ID: From: Christopher Morrow To: Pradosh Mohapatra Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 17:53:21 -0000 On Fri, Apr 8, 2011 at 1:49 PM, Pradosh Mohapatra wrote: >> not sure if mandating a single transport is needed at all. >> >> since the pros and cons of the various transport protocols >> (TCP, TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not simply >> enumerating the choices and leave it to the operator's local security policy >> which one to deploy ? >> >> IMO you cannot dictate local security policy as they are different between >> operators. also if the level of containment is sufficiently enough (e.g. >> local-cache only reachable through vrf, not accessible through internet >> it is perfectly reasonable even to load your cache records using vanilla TCP.) > > I have no problem listing various transports. I thought there was a suggestion to > keep one of them mandatory to encourage better interoperability. That makes > some sense. I believe, and Randy/authors can jump in here, the point of a MUST was to ensure we had one (at least) transport across all parts of the system. (interoperability, yes). How about authors/hannes/pradosh work out their best guess and we go from there? say by monday? :) -Chris From Sandra.Murphy@cobham.com Fri Apr 8 10:58:59 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92AF3A69D6 for ; Fri, 8 Apr 2011 10:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHn8AAbrPMPx for ; Fri, 8 Apr 2011 10:58:59 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id D74C73A68E0 for ; Fri, 8 Apr 2011 10:58:58 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p38I0gD9018956; Fri, 8 Apr 2011 13:00:42 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p38I0gLo024390; Fri, 8 Apr 2011 13:00:42 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.170]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 14:00:37 -0400 Date: Fri, 8 Apr 2011 14:00:35 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Hannes Gredler In-Reply-To: <20110408170400.GC11350@juniper.net> Message-ID: References: <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> <20110408170400.GC11350@juniper.net> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 08 Apr 2011 18:00:38.0479 (UTC) FILETIME=[DE053DF0:01CBF616] Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 17:58:59 -0000 On Fri, 8 Apr 2011, Hannes Gredler wrote: > On Thu, Apr 07, 2011 at 09:20:05PM -0700, Pradosh Mohapatra wrote: > | > We seem to be in a bit of a jam :( I don't think SIDR is going to be > | > able to, by declaration, get opensource implementations of AO to > | > appear. I don't see non-open-source implementations on the server side > | > for tcp-md5 sadly either, but at least fbsd/obsd/linux have tcp-md5 > | > support. > | > | We don't seem to be converging. I would suggest that we keep the status quo > | and make ssh mandatory to implement. Other mechanisms may get prescribed > | in future as & when they become commonly available. > > not sure if mandating a single transport is needed at all. > > since the pros and cons of the various transport protocols > (TCP, TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not simply > enumerating the choices and leave it to the operator's local security policy > which one to deploy ? Leaving it up to operator choice still leaves the question of what will be implemented. If we don't have a mandatory to implement protocol, can we be sure that an operator will have interoperating implementations wrt secure transport protocols from which to choose? --Sandy, as member only > > IMO you cannot dictate local security policy as they are different between > operators. also if the level of containment is sufficiently enough (e.g. > local-cache only reachable through vrf, not accessible through internet > it is perfectly reasonable even to load your cache records using vanilla TCP.) > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Fri Apr 8 11:00:44 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840DC3A69F4 for ; Fri, 8 Apr 2011 11:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 Lw0NntRi8bjd for ; Fri, 8 Apr 2011 11:00:44 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 183073A68E0 for ; Fri, 8 Apr 2011 11:00:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q8Fzd-000EEk-7s; Fri, 08 Apr 2011 18:01:13 +0000 Date: Fri, 08 Apr 2011 11:01:12 -0700 Message-ID: From: Randy Bush To: Hannes Gredler In-Reply-To: <20110408170400.GC11350@juniper.net> References: <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> <20110408170400.GC11350@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 18:00:44 -0000 > since the pros and cons of the various transport protocols (TCP, > TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not simply > enumerating the choices and leave it to the operator's local security > policy which one to deploy ? guaranteed inter-op would be nice. would prefer not to have "you can run server A with router X but not with router Y. Y needs server B. so you need to fully deploy two classes of servers." randy From gih@apnic.net Sat Apr 9 08:21:42 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14E43A6938 for ; Sat, 9 Apr 2011 08:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.704 X-Spam-Level: X-Spam-Status: No, score=-94.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_NUMERIC_HELO=2.067, 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 l3RtyuoswXMK for ; Sat, 9 Apr 2011 08:21:42 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id C01CC3A690C for ; Sat, 9 Apr 2011 08:21:41 -0700 (PDT) Received: from 4.75.240.10.in-addr.arpa (m1f0436d0.tmodns.net [208.54.4.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C0BBBB6826; Sun, 10 Apr 2011 01:23:24 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sun, 10 Apr 2011 01:23:19 +1000 Content-Transfer-Encoding: 7bit Message-Id: <52A86E31-B019-4435-B931-7F71C0D77829@apnic.net> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> To: Pradosh Mohapatra X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 15:21:42 -0000 On 08/04/2011, at 2:20 PM, Pradosh Mohapatra wrote: >> We seem to be in a bit of a jam :( I don't think SIDR is going to be >> able to, by declaration, get opensource implementations of AO to >> appear. I don't see non-open-source implementations on the server side >> for tcp-md5 sadly either, but at least fbsd/obsd/linux have tcp-md5 >> support. > > We don't seem to be converging. I would suggest that we keep the status quo > and make ssh mandatory to implement. Other mechanisms may get prescribed > in future as & when they become commonly available. > this sounds sensible to me Geoff From gih@apnic.net Sat Apr 9 08:27:42 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53193A6876 for ; Sat, 9 Apr 2011 08:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.704 X-Spam-Level: X-Spam-Status: No, score=-94.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_NUMERIC_HELO=2.067, 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 7UX5+ovefEbc for ; Sat, 9 Apr 2011 08:27:42 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 8E1793A6835 for ; Sat, 9 Apr 2011 08:27:41 -0700 (PDT) Received: from 4.75.240.10.in-addr.arpa (m1f0436d0.tmodns.net [208.54.4.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 3BCFAB6826; Sun, 10 Apr 2011 01:29:24 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <4A88F7EC-12D4-4AAA-92BE-D6A8BEACF776@cisco.com> Date: Sun, 10 Apr 2011 01:29:21 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> <20110408170400.GC11350@juniper.net> <4A88F7EC-12D4-4AAA-92BE-D6A8BEACF776@cisco.com> To: Hannes Gredler X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 15:27:42 -0000 On 09/04/2011, at 3:49 AM, Pradosh Mohapatra wrote: >> not sure if mandating a single transport is needed at all. >>=20 >> since the pros and cons of the various transport protocols >> (TCP, TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not = simply >> enumerating the choices and leave it to the operator's local security = policy >> which one to deploy ? >>=20 >> IMO you cannot dictate local security policy as they are different = between >> operators. also if the level of containment is sufficiently enough = (e.g. >> local-cache only reachable through vrf, not accessible through = internet >> it is perfectly reasonable even to load your cache records using = vanilla TCP.) >=20 > I have no problem listing various transports. I thought there was a = suggestion to > keep one of them mandatory to encourage better interoperability. That = makes > some sense. Frankly the interoperability argument is a very strong one for me. Yes, = at every step and with every component of this design we could enumerate a = laundry list of possible technologies, but, frankly, it seems like a less than useful = exercise of constructing complexity and threatening interoperability of the = resultant system. If the intention is to produce robust specifications that allow = cleanly interoperable implementations then it makes sense for me to produce a=20 specification that makes specific selections from the choice set. Geoff From hannes@juniper.net Sat Apr 9 13:42:37 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82EC13A6976 for ; Sat, 9 Apr 2011 13:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJomTD5QyBdw for ; Sat, 9 Apr 2011 13:42:36 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 669603A694F for ; Sat, 9 Apr 2011 13:42:33 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTaDFIr6cJQ1nsXjMCWtNC7P5IEj/u/NX@postini.com; Sat, 09 Apr 2011 13:44:23 PDT Received: from hannes-755.juniper.net (172.30.152.52) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.2.254.0; Sat, 9 Apr 2011 13:41:31 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id AD4B822545; Sat, 9 Apr 2011 22:43:34 +0200 (CEST) Date: Sat, 9 Apr 2011 22:43:34 +0200 From: Hannes Gredler To: Geoff Huston Message-ID: <20110409204334.GB16327@juniper.net> References: <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> <20110408170400.GC11350@juniper.net> <4A88F7EC-12D4-4AAA-92BE-D6A8BEACF776@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 20:42:37 -0000 On Sun, Apr 10, 2011 at 01:29:21AM +1000, Geoff Huston wrote: | | On 09/04/2011, at 3:49 AM, Pradosh Mohapatra wrote: | | >> not sure if mandating a single transport is needed at all. | >> | >> since the pros and cons of the various transport protocols | >> (TCP, TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not simply | >> enumerating the choices and leave it to the operator's local security policy | >> which one to deploy ? | >> | >> IMO you cannot dictate local security policy as they are different between | >> operators. also if the level of containment is sufficiently enough (e.g. | >> local-cache only reachable through vrf, not accessible through internet | >> it is perfectly reasonable even to load your cache records using vanilla TCP.) | > | > I have no problem listing various transports. I thought there was a suggestion to | > keep one of them mandatory to encourage better interoperability. That makes | > some sense. | | Frankly the interoperability argument is a very strong one for me. Yes, at every | step and with every component of this design we could enumerate a laundry list | of possible technologies, but, frankly, it seems like a less than useful exercise | of constructing complexity and threatening interoperability of the resultant | system. If the intention is to produce robust specifications that allow cleanly | interoperable implementations then it makes sense for me to produce a | specification that makes specific selections from the choice set. the question is *what* is that we try to standardize ? - is it 1. the application level communication protocol between caches and routers 2. the application level communication protocol between caches and routers and the transport ? i do not really buy the interop argument as early interop testing has showed that there are already several transports available to carry the rtr-cache protocol (BTW including vanilla TCP.) furthermore how should one read the spec ? - is a rtr-cache protocol implementation doing IPSEC *not* compliant and if so what are the technical arguments against it ? in the spirit of good layering we should really focus on the application protocol and not trying to crawl down the entire stack and securing each and every layer. where does it stop ? i mean shall we include DoS mitigation schemes at L3 and L2 ? clearly not - that is the operators choice and so is to take care of transport level security. From waehlisch@ieee.org Sat Apr 9 14:55:22 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0773A6958 for ; Sat, 9 Apr 2011 14:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.692 X-Spam-Level: X-Spam-Status: No, score=-101.692 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 KzNMBBVtzrRw for ; Sat, 9 Apr 2011 14:55:21 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 6714A3A696F for ; Sat, 9 Apr 2011 14:55:21 -0700 (PDT) Envelope-to: sidr@ietf.org Received: from g231224086.adsl.alicedsl.de ([92.231.224.86] helo=mw-PC.fritz.box) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q8g7g-000Fag-5q; Sat, 09 Apr 2011 23:55:16 +0200 Date: Sat, 9 Apr 2011 23:57:01 +0200 From: Matthias Waehlisch To: Hannes Gredler In-Reply-To: <20110409204334.GB16327@juniper.net> Message-ID: References: <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> <20110408170400.GC11350@juniper.net> <4A88F7EC-12D4-4AAA-92BE-D6A8BEACF776@cisco.com> <20110409204334.GB16327@juniper.net> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 21:55:22 -0000 Hi Hannes, On Sat, 9 Apr 2011, Hannes Gredler wrote: > | > I have no problem listing various transports. I thought there was a suggestion to > | > keep one of them mandatory to encourage better interoperability. That makes > | > some sense. > | > | Frankly the interoperability argument is a very strong one for me. Yes, at every > | step and with every component of this design we could enumerate a laundry list > | of possible technologies, but, frankly, it seems like a less than useful exercise > | of constructing complexity and threatening interoperability of the resultant > | system. If the intention is to produce robust specifications that allow cleanly > | interoperable implementations then it makes sense for me to produce a > | specification that makes specific selections from the choice set. > > the question is *what* is that we try to standardize ? - is it > > 1. the application level communication protocol between caches and routers > 2. the application level communication protocol between caches and routers > and the transport ? > it's 1. However, an (inherent) requirement of the protocol is (a) to deliver the data such that it is authenticated and (b) the integrity of the data can be verified. Otherwise, at least from my perspective, the protocol would be useful. Leaving the mechanism for authentication and integrity undefined would result in a not well-defined protocol. From an implementation and deployment perspective, this is quite painful. We do not breach the "spirit of good layering" if we precisely define how this requirement can be achieved. Maybe, the question is if there is anything else to achieve the goals, which is not out-dated, implemented, and beyond the current suggestions. Best regards matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From kent@bbn.com Mon Apr 11 15:30:48 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A86DAE06C1 for ; Mon, 11 Apr 2011 15:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13O-8DdK+onx for ; Mon, 11 Apr 2011 15:30:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id DBC46E06C0 for ; Mon, 11 Apr 2011 15:30:43 -0700 (PDT) Received: from dhcp89-089-127.bbn.com ([128.89.89.127]:49171 helo=[128.89.89.213]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q9NAK-000FkW-HW; Mon, 11 Apr 2011 15:52:52 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> Date: Mon, 11 Apr 2011 15:49:46 -0400 To: Brian Weis From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 22:30:48 -0000 At 9:30 PM -0700 4/6/11, Brian Weis wrote: >On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: > >>> Getting a new application (such as the rtr protocol) specifying >>> hmac-md5 mandatory to implement through a Secdir review and then the >>> Security ADs just won't happen. The only exception I can think of is >>> if there were no possible alternatives, and that's obviously not the >>> case here. >> >> with AO not implemented on any servers, routers not having ssh >> libraries, and this being a server to router protocol, what are the >> alternatives? >> >> randy > >I'm surprised IPsec hasn't been mentioned in this thread ... was it >previously discussed and rejected? Correct me if I'm wrong, but I >believe it's common for BGP routers to support IPsec and servers >definitely support IPsec. On the router side, one or two IPsec >sessions to servers should not be a burden. I'm less sure of the >server IPsec scaling properties, but I would expect a LINUX or BSD >kernel to have the scaling issues as were discussed earlier in this >thread regarding SSH but I'm no expert here. > >Brian A few years ago we were told by vendors that many router implementations of IPsec were available only to traffic passing through a router, not to the control plane terminating in a router. Unless that has changed, IPsec is not a good candidate here. Steve From Internet-Drafts@ietf.org Wed Apr 13 03:45:03 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8AE4FE06F2; Wed, 13 Apr 2011 03:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JtWuUpGaOxH; Wed, 13 Apr 2011 03:45:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EF645E0692; Wed, 13 Apr 2011 03:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.50 Message-ID: <20110413104502.16849.45642.idtracker@ietfc.amsl.com> Date: Wed, 13 Apr 2011 03:45:02 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-ta-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Resource Certificate PKI (RPKI) Trust Anchor Locator Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-ta-07.txt Pages : 8 Date : 2011-04-13 This document defines a Trust Anchor Locator (TAL) for the Resource Certificate Public Key Infrastructure (RPKI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ta-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-ta-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-13034424.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Apr 13 04:30:05 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2F6AFE0722; Wed, 13 Apr 2011 04:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBJ3hahd3Zh6; Wed, 13 Apr 2011 04:30:04 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2078CE06E0; Wed, 13 Apr 2011 04:30:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.50 Message-ID: <20110413113004.31681.42088.idtracker@ietfc.amsl.com> Date: Wed, 13 Apr 2011 04:30:04 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-manifests-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:30:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Manifests for the Resource Public Key Infrastructure Author(s) : R. Austein, et al. Filename : draft-ietf-sidr-rpki-manifests-10.txt Pages : 19 Date : 2011-04-13 This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority, that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-manifests-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-13042316.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Apr 13 06:30:04 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DADC1E0759; Wed, 13 Apr 2011 06:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9jDOJ89QSze; Wed, 13 Apr 2011 06:30:03 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E4A00E0742; Wed, 13 Apr 2011 06:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.50 Message-ID: <20110413133003.5392.99599.idtracker@ietfc.amsl.com> Date: Wed, 13 Apr 2011 06:30:03 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-algs-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 13:30:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure Author(s) : G. Huston Filename : draft-ietf-sidr-rpki-algs-05.txt Pages : 6 Date : 2011-04-13 This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format for the Resource Public Key Infrastructure subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the Relying Parties (RPs) that verify these digital signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-algs-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-algs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-13062214.I-D@ietf.org> --NextPart-- From raszuk@cisco.com Thu Apr 14 04:13:21 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AEF55E06C1; Thu, 14 Apr 2011 04:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0O9FaImVt24; Thu, 14 Apr 2011 04:13:21 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id CE551E0670; Thu, 14 Apr 2011 04:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=814; q=dns/txt; s=iport; t=1302779600; x=1303989200; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/SX7B5+Hzp2lNe+kP5Kb8s+TIuvKgLPgqFxE0I6/B/c=; b=djE6Rf6VQAVTNbLrYcb4rRiYtJINIds/wlEYrKc5tFnfy0/37fqzHr3V OsluiB2BcM3QhQfb+f8bYiiM3IFBTFu/AXoMuvI5bTSBIOoLtSodX1QE6 EEZEHOGoqg7rCQRhKM49wX2XUoKuA6x2o+bbCJfZyIShJLITEO6hVym2G 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloKAGrWpk2rRDoI/2dsb2JhbAClaXeBBh6HS5wKgnMOAZl0hW4EjW+Dcw X-IronPort-AV: E=Sophos;i="4.64,210,1301875200"; d="scan'208";a="681114379" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2011 11:13:20 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3EBDIjT002837; Thu, 14 Apr 2011 11:13:19 GMT Message-ID: <4DA6D6C8.2040304@cisco.com> Date: Thu, 14 Apr 2011 13:13:12 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: idr@ietf.org, sidr@ietf.org References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: john heasley Subject: Re: [sidr] [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 11:13:21 -0000 > no. it is telling the edge site, your paying customer, that they can > secure their prefix without upgrading hardware. Can anyone in IDR or SIDR demystify for us here what securing BGP really requires (certificates, signatures, attestations you name it) if to secure a single prefix originated by customer site requires more then 4K of BGP message size ? We already know that update packing is gone and that there is going to be single NLRI per update. OK or NOK but a different debate for different time. But if securing 1 prefix really requires more then 4K of data attached to it I think we should question the entire approach rather then waist time to argue about draft-ymbk-bgp-extended-messages. Well unless this secure BGP is the only reason for this draft ;-). Thx, R. From kent@bbn.com Fri Apr 15 08:46:35 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 82067E070B; Fri, 15 Apr 2011 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7hY+xHJmZeA; Fri, 15 Apr 2011 08:46:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id 01802E069F; Fri, 15 Apr 2011 08:46:35 -0700 (PDT) Received: from dhcp89-089-062.bbn.com ([128.89.89.62]:49204) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAlEA-000E0W-CH; Fri, 15 Apr 2011 11:46:34 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DA6D6C8.2040304@cisco.com> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> <4DA6D6C8.2040304@cisco.com> Date: Fri, 15 Apr 2011 11:46:24 -0400 To: raszuk@cisco.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: john heasley , idr@ietf.org, sidr@ietf.org Subject: Re: [sidr] [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:46:35 -0000 At 1:13 PM +0200 4/14/11, Robert Raszuk wrote: >>no. it is telling the edge site, your paying customer, that they can >>secure their prefix without upgrading hardware. > >Can anyone in IDR or SIDR demystify for us here what securing BGP >really requires (certificates, signatures, attestations you name it) >if to secure a single prefix originated by customer site requires >more then 4K of BGP message size ? BGPSEC calls for each AS hop along a path to sign AS path info. Although the average path length is a bit less than 4 hops, there are some very long paths that appear in FIBs, e.g., over 20 hops. The desire to increase the max UPADTE size (from the current 4K limit) is intended to accommodate very long paths. The principle contributor to the size increase is the digital signature. If on users RSA, each signature would be at least 1K bytes, and might be 2K bytes, depending on the key length size chosen. So, a 20-hop path could yield a 20-40K set of sigs, independent of the other path security data. The good news is that many long paths contain repeated AS#s, which could be collapsed into a single signature. But, that optimization has not yet been explored. Also, if we were to use DSA or ECDSA as a signature algorithm, instead of RSA, the signature size could drop to 128 or 256 bytes, from 1-2K, a savings of a factor of 4-8. Still, a 20-hop path, with no repeats, might not fit in a 4K UPDATE, with all of the other secruity data. Hope that explanation helps. Steve From raszuk@cisco.com Fri Apr 15 08:59:03 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 13EB6E087C; Fri, 15 Apr 2011 08:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqHBk16bZnvj; Fri, 15 Apr 2011 08:58:58 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 92DF8E06A9; Fri, 15 Apr 2011 08:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=2519; q=dns/txt; s=iport; t=1302883138; x=1304092738; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9+6RUeu4zkJKCrJ0heNWbIYqVKzf44O4XsUuE5MmUOs=; b=LtTQajISoDSDdYR3E73kbwgbGRU68wnjKyt9IQgcssXCA93B1O7fTC8f z7U8iO3DxeK618t5OIrOknat3+USGmUFuW258nvmW55vP8faILZDOx8gx BM7oPzYh+O4CbKQsFt5iDsbPpq9JrwqfMEeWX6V6k4gqE1Nb4fRpYg4J5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGpqqE2rRDoH/2dsb2JhbACmBHeIb55tgnQOAZl7hW4EjXiDdA X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="431018974" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2011 15:58:57 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3FFwt1g030278; Fri, 15 Apr 2011 15:58:56 GMT Message-ID: <4DA86B39.8090008@cisco.com> Date: Fri, 15 Apr 2011 17:58:49 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Stephen Kent References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> <4DA6D6C8.2040304@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: john heasley , idr@ietf.org, sidr@ietf.org Subject: Re: [sidr] [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:59:03 -0000 Hi Stephen, This is really great explanation. I did try to find this in some papers and your slides but I could not. So it confirms that even if we use "worse case" BGP update advertised by customer to provider (1 hop only case) it will fit within 4K limit easily. Of course for any subsequent advertisement we need increase the message size and this is where the draft-ymbk-bgp-extended-messages addresses the issue. One sentence in your reply is still not clear: > If on users RSA, each signature would be at least 1K bytes, and might > be 2K bytes, depending on the key length size chosen. So, a 20-hop > path could yield a 20-40K set of sigs, independent of the other path > security data. - What is the maximum key length possible and how big would be the RSA signature with such key length ? - What are the other path security data and what their size might be min-max. Many thx again, R. > At 1:13 PM +0200 4/14/11, Robert Raszuk wrote: >>> no. it is telling the edge site, your paying customer, that they >>> can secure their prefix without upgrading hardware. >> >> Can anyone in IDR or SIDR demystify for us here what securing BGP >> really requires (certificates, signatures, attestations you name >> it) if to secure a single prefix originated by customer site >> requires more then 4K of BGP message size ? > > BGPSEC calls for each AS hop along a path to sign AS path info. > Although the average path length is a bit less than 4 hops, there are > some very long paths that appear in FIBs, e.g., over 20 hops. The > desire to increase the max UPADTE size (from the current 4K limit) is > intended to accommodate very long paths. The principle contributor to > the size increase is the digital signature. If on users RSA, each > signature would be at least 1K bytes, and might be 2K bytes, > depending on the key length size chosen. So, a 20-hop path could > yield a 20-40K set of sigs, independent of the other path security > data. > > The good news is that many long paths contain repeated AS#s, which > could be collapsed into a single signature. But, that optimization > has not yet been explored. Also, if we were to use DSA or ECDSA as a > signature algorithm, instead of RSA, the signature size could drop to > 128 or 256 bytes, from 1-2K, a savings of a factor of 4-8. Still, a > 20-hop path, with no repeats, might not fit in a 4K UPDATE, with all > of the other secruity data. > > Hope that explanation helps. > > Steve > From kent@bbn.com Fri Apr 15 12:12:24 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2EB9FE0774; Fri, 15 Apr 2011 12:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aI0ZxN9dExwt; Fri, 15 Apr 2011 12:12:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id 8A2B1E0749; Fri, 15 Apr 2011 12:12:22 -0700 (PDT) Received: from dhcp89-089-062.bbn.com ([128.89.89.62]:49217) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAoRK-0006dR-7i; Fri, 15 Apr 2011 15:12:22 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DA86B39.8090008@cisco.com> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> <4DA6D6C8.2040304@cisco.com> <4DA86B39.8090008@cisco.com> Date: Fri, 15 Apr 2011 15:12:12 -0400 To: raszuk@cisco.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: idr@ietf.org, sidr@ietf.org Subject: Re: [sidr] [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 19:12:24 -0000 Robert, First let me apologize as I accidentally put in "bytes" where I meant "bits" in the examples I provided. Whoops! RSA 2K keys are 2K bits, i.e., 256 bytes (not 2K bytes). And, 2K RSA sig is the default, as this matches the key sizes we have already agreed upon for the RPKI certs. Still, a 20-hop path with RSA 2K (bit) sigs exceeds the 4K (byte) max UPDATE size, without any other overhead. Sorry for the confusion. > >- What is the maximum key length possible and how big would be the >RSA signature with such key length ? There is no max key size, but it does not make sense to push for bigger RSA key sizes, instead of moving to more efficient (in space and computation) sig algorithms. The sig size for RSA is the same size as the key. The likely sucessor algs are DSA or EC-DSA, which use smaller keys, but offer secruity equivalent to the larger RSA key sizes. The key sizes for those algorithms yield 128 or 256-bit sigs, under current hash algs. >- What are the other path security data and what their size might be min-max. I defer to Matt Lepinski for the details of the other data, as he is the author of the BGPSEC protocol doc. Steve From gih@apnic.net Fri Apr 15 13:09:22 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0FAACE0687; Fri, 15 Apr 2011 13:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.704 X-Spam-Level: X-Spam-Status: No, score=-94.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Tc7wkYr1DTD; Fri, 15 Apr 2011 13:09:21 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfc.amsl.com (Postfix) with ESMTP id BA0CFE06D1; Fri, 15 Apr 2011 13:09:20 -0700 (PDT) Received: from 203.35.240.10.in-addr.arpa (mac5f36d0.tmodns.net [208.54.95.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 0C615B68C4; Sat, 16 Apr 2011 06:09:16 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sat, 16 Apr 2011 06:09:10 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <169088F7-4722-41EA-9E6B-C3BC8D20D813@apnic.net> References: <201104140459.p3E4x6qr030769@harbor.orleans.occnc.com> <4ed4851e-f4eb-4750-a965-07e877144727@email.android.com> <4DA69424.3080202@cisco.com> <20110414065648.GB8492@shrubbery.net> <4DA6D6C8.2040304@cisco.com> <4DA86B39.8090008@cisco.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org, idr@ietf.org Subject: Re: [sidr] [Idr] draft-ymbk-bgp-extended-messages-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 20:09:22 -0000 On 16/04/2011, at 5:12 AM, Stephen Kent wrote: > Robert, >=20 > First let me apologize as I accidentally put in "bytes" where I meant = "bits" in the examples I provided. Whoops! RSA 2K keys are 2K bits, = i.e., 256 bytes (not 2K bytes). And, 2K RSA sig is the default, as this = matches the key sizes we have already agreed upon for the RPKI certs. = Still, a 20-hop path with RSA 2K (bit) sigs exceeds the 4K (byte) max = UPDATE size, without any other overhead. Sorry for the confusion. >=20 >>=20 >> - What is the maximum key length possible and how big would be the = RSA signature with such key length ? >=20 > There is no max key size, but it does not make sense to push for = bigger RSA > key sizes, instead of moving to more efficient (in space and = computation) sig algorithms. The sig size for RSA is the same size as = the key. >=20 > The likely sucessor algs are DSA or EC-DSA, which use smaller keys, = but offer secruity equivalent to the larger RSA key sizes. The key sizes = for those algorithms yield 128 or 256-bit sigs, under current hash algs. >=20 >> - What are the other path security data and what their size might be = min-max. >=20 > I defer to Matt Lepinski for the details of the other data, as he is = the author of the BGPSEC protocol doc. I was doing a similar mental sum in my head and 256 bytes per sig is not = a lot. As far as I am aware the only other added per-AS part of the = attribute is the SKI of the public key. Presumably this is also 256 = bytes. SO thats 500 bytes per AS, and for a 20 AS path thats 10K in additional = data. Is my back of the envelope anywhere near in the right ball park? Geoff= From benno@NLnetLabs.nl Mon Apr 18 07:42:09 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5A72AE0770 for ; Mon, 18 Apr 2011 07:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FqHTMNNm2R4 for ; Mon, 18 Apr 2011 07:42:08 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id 78615E06D9 for ; Mon, 18 Apr 2011 07:42:08 -0700 (PDT) Received: from aluminum.nlnetlabs.nl (aluminum.nlnetlabs.nl [IPv6:2001:7b8:206:1:21b:63ff:feb8:a9eb]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p3IEg7J5007357 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 18 Apr 2011 16:42:07 +0200 (CEST) (envelope-from benno@NLnetLabs.nl) Message-ID: <4DAC4DBF.9020308@NLnetLabs.nl> Date: Mon, 18 Apr 2011 16:42:07 +0200 From: Benno Overeinder User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: sidr@ietf.org References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6AE16@PLSWM12A.ad.sprint.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6AE16@PLSWM12A.ad.sprint.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 18 Apr 2011 16:42:07 +0200 (CEST) Subject: Re: [sidr] BCP for implementing RPKI? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:42:09 -0000 On 4/4/11 2:17 AM, George, Wes E [NTK] wrote: > I had a conversation with a couple of folks while at IETF that they thought I should bring to the list for discussion. > > While we have an operational considerations document that covers origin validation, it focuses mainly on policy and implementation > details of the validation machinery. We don't have anything that covers the back-end of implementing a proper RPKI (from the cache > upward, rather than downward towards the router). We (SURFnet and NLnet Labs) are running an RPKI pilot project to find answers to the same/similar questions. I was also thinking of a BCP, but I was not sure as it might be quite operational oriented. I think we are more than happy to share insights and contribute to such a document, BCP or in any other form. Best, -- Benno -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From iesg-secretary@ietf.org Mon Apr 18 11:20:08 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7F966E083C; Mon, 18 Apr 2011 11:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KviULhcBQ0RH; Mon, 18 Apr 2011 11:20:07 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3A5E4E083E; Mon, 18 Apr 2011 11:20:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110418182007.8202.76058.idtracker@ietfc.amsl.com> Date: Mon, 18 Apr 2011 11:20:07 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure' to Proposed Standard (draft-ietf-sidr-rpki-algs-05.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:20:08 -0000 The IESG has approved the following document: - 'The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure' (draft-ietf-sidr-rpki-algs-05.txt) as a Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-algs/ Technical Summary This document defines a profile for the algorithm and key size to be used for signatures applied to certificates, Certificate Revocation Lists, and signed objects in the context of the Resource Public Key Infrastructure. Working Group Summary The profile for algorithm and key size was originally part of the certificate profile. The working group realized that this information might be used in other drafts as well, so for ease of reference a separate document was produced. Furthermore, using a separate document for this profile means that future changes in the algorithm requirements will no longer require a revision to the referring documents. Document Quality This document is well written and clear. Although this profile does not define a protocol, several independent implementations of the certificate profile exist, which would also involve implementing this algorithm profile, indicating careful review. Personnel Sandra Murphy is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. From iesg-secretary@ietf.org Mon Apr 18 11:22:06 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 003F3E0856; Mon, 18 Apr 2011 11:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaGiIqjE22Ya; Mon, 18 Apr 2011 11:22:05 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 31154E0858; Mon, 18 Apr 2011 11:22:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110418182205.8817.19934.idtracker@ietfc.amsl.com> Date: Mon, 18 Apr 2011 11:22:05 -0700 Cc: sidr mailing list , sidr chair , RFC Editor Subject: [sidr] Protocol Action: 'Resource Certificate PKI (RPKI) Trust Anchor Locator' to Proposed Standard (draft-ietf-sidr-ta-07.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:22:06 -0000 The IESG has approved the following document: - 'Resource Certificate PKI (RPKI) Trust Anchor Locator' (draft-ietf-sidr-ta-07.txt) as a Proposed Standard This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-ta/ Technical Summary This document defines a Trust Anchor Locator (TAL) for the Resource Certificate Public Key Infrastructure (RPKI). Working Group Summary Originally, the draft suggested a dual certificate profile for the publication of trust anchor material more directly. The working group found that profile to be too complicated and preferred a simpler solution. Document Quality The document is well written and at least two independent implementations exist. Personnel Sandra Murphy is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. From Sandra.Murphy@cobham.com Tue Apr 19 04:24:46 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ACA97E073F for ; Tue, 19 Apr 2011 04:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BXzEVObfvrj for ; Tue, 19 Apr 2011 04:24:46 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfc.amsl.com (Postfix) with ESMTP id 0B2BFE0732 for ; Tue, 19 Apr 2011 04:24:45 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p3JBOjNj023261 for ; Tue, 19 Apr 2011 06:24:45 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p3JBOjCD029994 for ; Tue, 19 Apr 2011 06:24:45 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.104]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 07:24:44 -0400 Date: Tue, 19 Apr 2011 07:24:44 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 19 Apr 2011 11:24:45.0030 (UTC) FILETIME=[6267D060:01CBFE84] Subject: [sidr] wg adoption for draft wrt recharter items X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:24:46 -0000 The sidr re-charter starts off with the following new items: Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation Mar 2011 Jun 2012 A document describing threats to the routing system Mar 2011 Jun 2012 A requirements document that addresses these threats Mar 2011 Jan 2012 Document the BGP protocol enhancements that meet the security requirements Mar 2011 Jul 2012 Operational deployment guidance for network operators In the meeting on 1 April, there were presentations of individual submissions that could meet those recharter items. In that meeting, a verbal call for adoption as wg drafts was positive. As always, all such meeting decisions must be taken to the mailing list. I am about to issue calls for wg adoption for these drafts, to see if the wg agrees to take on the draft as a wg draft. Note that there is no need to agree with all the content of the draft to agree to its adoption as a wg draft. All draft editors are required to reflect the consensus of the working group. --Sandy, speaking as wg co-chair with wg ceremonial garb donned. From Sandra.Murphy@cobham.com Tue Apr 19 04:26:09 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DEDF7E0748 for ; Tue, 19 Apr 2011 04:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCxYfcvMOvwY for ; Tue, 19 Apr 2011 04:26:05 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfc.amsl.com (Postfix) with ESMTP id 661F3E0732 for ; Tue, 19 Apr 2011 04:26:05 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p3JBQ4fU023265 for ; Tue, 19 Apr 2011 06:26:04 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p3JBQ2i6030035 for ; Tue, 19 Apr 2011 06:26:05 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.104]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 07:26:02 -0400 Date: Tue, 19 Apr 2011 07:26:02 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 19 Apr 2011 11:26:02.0873 (UTC) FILETIME=[90CDB690:01CBFE84] Subject: [sidr] call for adoption of draft-kent-bgpsec-threats-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:26:10 -0000 The working group has been requested to adopt draft-kent-bgpsec-threats-01 as a working group draft, to satisfy the following item on our charter: ID Date Pub Date Mar 2011 Jun 2012 A document describing threats to the routing system Please respond to the list with your opinion as to whether you accept this draft as a working group draft and are willing to work on it. Remember that you do not need to accept all content in a draft to adopt, as draft editors are required to reflect the consensus of the working group. This call will end 3 May 2011. --Sandy, speaking as wg co-chair, with wg ceremonial garb donned From Sandra.Murphy@cobham.com Tue Apr 19 04:27:44 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AF354E0749 for ; Tue, 19 Apr 2011 04:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyEBL-tpOalv for ; Tue, 19 Apr 2011 04:27:44 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfc.amsl.com (Postfix) with ESMTP id 428B7E0748 for ; Tue, 19 Apr 2011 04:27:44 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p3JBRhZB023281 for ; Tue, 19 Apr 2011 06:27:43 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p3JBRh8D030082 for ; Tue, 19 Apr 2011 06:27:44 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.104]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 07:27:43 -0400 Date: Tue, 19 Apr 2011 07:27:43 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 19 Apr 2011 11:27:43.0904 (UTC) FILETIME=[CD05D200:01CBFE84] Subject: [sidr] call for adoption of draft-ymbk-bgpsec-reqs-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:27:44 -0000 The working group has been requested to adopt draft-ymbk-bgpsec-reqs-02 as a working group draft, to satisfy the following item on our charter: ID Date Pub Date Mar 2011 Jun 2012 A requirements document that addresses these threats Please respond to the list with your opinion as to whether you accept this draft as a working group draft and are willing to work on it. Remember that you do not need to accept all content in a draft to adopt, as draft editors are required to reflect the consensus of the working group. This call will end 3 May 2011. --Sandy, speaking as wg co-chair, with wg ceremonial garb donned From Sandra.Murphy@cobham.com Tue Apr 19 04:29:07 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A4D62E0732 for ; Tue, 19 Apr 2011 04:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDXvyx1tS7TK for ; Tue, 19 Apr 2011 04:29:07 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfc.amsl.com (Postfix) with ESMTP id 2EDEBE06E0 for ; Tue, 19 Apr 2011 04:29:07 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p3JBT6BV023297 for ; Tue, 19 Apr 2011 06:29:06 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p3JBT6YC030113 for ; Tue, 19 Apr 2011 06:29:06 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.104]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 07:29:06 -0400 Date: Tue, 19 Apr 2011 07:29:06 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 19 Apr 2011 11:29:06.0794 (UTC) FILETIME=[FE6DD4A0:01CBFE84] Subject: [sidr] call for adoption of draft-lepinski-bgpsec-overview-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:29:07 -0000 The working group has been requested to adopt draft-lepinski-bgpsec-overview-00 as a working group draft, to satisfy the following item on our charter: ID Date Pub Date Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation Please respond to the list with your opinion as to whether you accept this draft as a working group draft and are willing to work on it. Remember that you do not need to accept all content in a draft to adopt, as draft editors are required to reflect the consensus of the working group. This call will end 3 May 2011. --Sandy, speaking as wg co-chair, with wg ceremonial garb donned From Sandra.Murphy@cobham.com Tue Apr 19 04:30:10 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 98DC1E0738 for ; Tue, 19 Apr 2011 04:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3VEjF4X5dMu for ; Tue, 19 Apr 2011 04:30:10 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfc.amsl.com (Postfix) with ESMTP id 1992AE0732 for ; Tue, 19 Apr 2011 04:30:10 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p3JBU9XT023322 for ; Tue, 19 Apr 2011 06:30:09 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p3JBU9Un030139 for ; Tue, 19 Apr 2011 06:30:09 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.104]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 07:30:09 -0400 Date: Tue, 19 Apr 2011 07:30:08 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 19 Apr 2011 11:30:09.0716 (UTC) FILETIME=[23EEF740:01CBFE85] Subject: [sidr] call for adoption of draft-lepinski-bgpsec-protocol-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:30:10 -0000 The working group has been requested to adopt draft-lepinski-bgpsec-protocol-00 as a working group draft, to satisfy the following item on our charter: ID Date Pub Date Mar 2011 Jan 2012 Document the BGP protocol enhancements that meet the security requirements Please respond to the list with your opinion as to whether you accept this draft as a working group draft and are willing to work on it. Remember that you do not need to accept all content in a draft to adopt, as draft editors are required to reflect the consensus of the working group. This call will end 3 May 2011. --Sandy, speaking as wg co-chair, with wg ceremonial garb donned From Sandra.Murphy@cobham.com Tue Apr 19 04:30:51 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 53038E0732 for ; Tue, 19 Apr 2011 04:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tY-VzzMzr6c for ; Tue, 19 Apr 2011 04:30:50 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfc.amsl.com (Postfix) with ESMTP id D14C6E06E0 for ; Tue, 19 Apr 2011 04:30:50 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p3JBUo7a023330 for ; Tue, 19 Apr 2011 06:30:50 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p3JBUoa8030157 for ; Tue, 19 Apr 2011 06:30:50 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.104]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 07:30:50 -0400 Date: Tue, 19 Apr 2011 07:30:49 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 19 Apr 2011 11:30:50.0497 (UTC) FILETIME=[3C3DA710:01CBFE85] Subject: [sidr] call for adoption of draft-ymbk-bgpsec-ops-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:30:51 -0000 The working group has been requested to adopt draft-ymbk-bgpsec-ops-01 as a working group draft, to satisfy the following item on our charter: ID Date Pub Date Mar 2011 Jul 2012 Operational deployment guidance for network operators Please respond to the list with your opinion as to whether you accept this draft as a working group draft and are willing to work on it. Remember that you do not need to accept all content in a draft to adopt, as draft editors are required to reflect the consensus of the working group. This call will end 3 May 2011. --Sandy, speaking as wg co-chair, with wg ceremonial garb donned From terry.manderson@icann.org Tue Apr 19 04:32:24 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 686B8E0732 for ; Tue, 19 Apr 2011 04:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwCtVupUTaPC for ; Tue, 19 Apr 2011 04:32:20 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfc.amsl.com (Postfix) with ESMTP id 292B0E073A for ; Tue, 19 Apr 2011 04:32:20 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 19 Apr 2011 04:32:18 -0700 From: Terry Manderson To: Sandra Murphy Date: Tue, 19 Apr 2011 04:32:16 -0700 Thread-Topic: [sidr] call for adoption of draft-kent-bgpsec-threats-01 Thread-Index: Acv+hXCpnAqP3koFTEu5eZIlo8Z8dQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] call for adoption of draft-kent-bgpsec-threats-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:32:24 -0000 I think this item should be WG document and I am willing to review and cont= ribute. Cheers, Terry On 19/04/2011, at 9:26 PM, "Sandra Murphy" wrote= : > The working group has been requested to adopt draft-kent-bgpsec-threats-0= 1=20 > as a working group draft, to satisfy the following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jun 2012 A document describing threats to the routing system >=20 > Please respond to the list with your opinion as to whether you accept thi= s > draft as a working group draft and are willing to work on it. Remember > that you do not need to accept all content in a draft to adopt, as draft > editors are required to reflect the consensus of the working group. >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From terry.manderson@icann.org Tue Apr 19 04:35:47 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A9100E06E0 for ; Tue, 19 Apr 2011 04:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8cVUHHqG7Z2 for ; Tue, 19 Apr 2011 04:35:47 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfc.amsl.com (Postfix) with ESMTP id 152ADE068E for ; Tue, 19 Apr 2011 04:35:47 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 19 Apr 2011 04:35:46 -0700 From: Terry Manderson To: Sandra Murphy Date: Tue, 19 Apr 2011 04:35:44 -0700 Thread-Topic: [sidr] call for adoption of draft-lepinski-bgpsec-overview-00 Thread-Index: Acv+hew/ap2nuZVfTD2RMNXjtfcEiQ== Message-ID: <1D89DDFB-F31B-435A-9903-9D003C33909D@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] call for adoption of draft-lepinski-bgpsec-overview-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:35:47 -0000 I think this item should be WG document and I am willing to review and cont= ribute. Cheers, Terry On 19/04/2011, at 9:29 PM, "Sandra Murphy" wrote= : > The working group has been requested to adopt=20 > draft-lepinski-bgpsec-overview-00 as a working group draft, to satisfy th= e=20 > following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes > required for origin and path validation >=20 > Please respond to the list with your opinion as to whether you accept thi= s=20 > draft as a working group draft and are willing to work on it. Remember=20 > that you do not need to accept all content in a draft to adopt, as draft= =20 > editors are required to reflect the consensus of the working group. >=20 >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From terry.manderson@icann.org Tue Apr 19 04:36:47 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9208DE0745 for ; Tue, 19 Apr 2011 04:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrCj0Q1ovBEi for ; Tue, 19 Apr 2011 04:36:47 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfc.amsl.com (Postfix) with ESMTP id E0B7CE068E for ; Tue, 19 Apr 2011 04:36:46 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 19 Apr 2011 04:36:45 -0700 From: Terry Manderson To: Sandra Murphy Date: Tue, 19 Apr 2011 04:36:43 -0700 Thread-Topic: [sidr] call for adoption of draft-lepinski-bgpsec-protocol-00 Thread-Index: Acv+hg+XrtRfTCvDQq+mWpr4nUkZ4g== Message-ID: <5FF550AD-55C1-4126-A773-7DCC70712C23@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] call for adoption of draft-lepinski-bgpsec-protocol-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:36:47 -0000 I think this item should be WG document and I am willing to review and cont= ribute. Cheers, Terry On 19/04/2011, at 9:30 PM, "Sandra Murphy" wrote= : > The working group has been requested to adopt=20 > draft-lepinski-bgpsec-protocol-00 as a working group draft, to satisfy th= e=20 > following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jan 2012 Document the BGP protocol enhancements that meet > the security requirements >=20 > Please respond to the list with your opinion as to whether you accept thi= s=20 > draft as a working group draft and are willing to work on it. Remember=20 > that you do not need to accept all content in a draft to adopt, as draft= =20 > editors are required to reflect the consensus of the working group. >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From terry.manderson@icann.org Tue Apr 19 04:38:36 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 83589E0748 for ; Tue, 19 Apr 2011 04:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0vo4BfNEV7B for ; Tue, 19 Apr 2011 04:38:36 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfc.amsl.com (Postfix) with ESMTP id DE4ACE06D9 for ; Tue, 19 Apr 2011 04:38:35 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 19 Apr 2011 04:38:35 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Tue, 19 Apr 2011 04:38:32 -0700 Thread-Topic: [sidr] call for adoption of draft-ymbk-bgpsec-ops-01 Thread-Index: Acv+hlDGzJ5BdihxR9aSE9A8f+yVRQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] call for adoption of draft-ymbk-bgpsec-ops-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:38:36 -0000 I think this item should be WG document and I am willing to review and cont= ribute. Cheers, Terry On 19/04/2011, at 9:31 PM, "Sandra Murphy" wrote= : > The working group has been requested to adopt draft-ymbk-bgpsec-ops-01 as= =20 > a working group draft, to satisfy the following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jul 2012 Operational deployment guidance for network=20 > operators >=20 >=20 > Please respond to the list with your opinion as to whether you accept thi= s > draft as a working group draft and are willing to work on it. Remember > that you do not need to accept all content in a draft to adopt, as draft > editors are required to reflect the consensus of the working group. >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From terry.manderson@icann.org Tue Apr 19 04:39:53 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92EF6E0745 for ; Tue, 19 Apr 2011 04:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adaC67owPre2 for ; Tue, 19 Apr 2011 04:39:53 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfc.amsl.com (Postfix) with ESMTP id F0373E06D9 for ; Tue, 19 Apr 2011 04:39:52 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 19 Apr 2011 04:39:51 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Tue, 19 Apr 2011 04:39:49 -0700 Thread-Topic: [sidr] call for adoption of draft-ymbk-bgpsec-reqs-02 Thread-Index: Acv+hn58lZW6wWuZRlezdJhhjN+xkw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] call for adoption of draft-ymbk-bgpsec-reqs-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:39:53 -0000 I think this item should be WG document and I am willing to review and cont= ribute. Cheers, Terry On 19/04/2011, at 9:28 PM, "Sandra Murphy" wrote= : > The working group has been requested to adopt draft-ymbk-bgpsec-reqs-02=20 > as a working group draft, to satisfy the following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jun 2012 A requirements document that addresses these threat= s >=20 >=20 > Please respond to the list with your opinion as to whether you accept thi= s > draft as a working group draft and are willing to work on it. Remember > that you do not need to accept all content in a draft to adopt, as draft > editors are required to reflect the consensus of the working group. >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Tue Apr 19 05:06:07 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 07F24E0693 for ; Tue, 19 Apr 2011 05:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6UYLRAfRCt6 for ; Tue, 19 Apr 2011 05:06:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 50A57E0674 for ; Tue, 19 Apr 2011 05:06:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QC9gx-0007yt-UT; Tue, 19 Apr 2011 12:06:04 +0000 Date: Tue, 19 Apr 2011 21:06:31 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-kent-bgpsec-threats-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 12:06:07 -0000 i support adoption From randy@psg.com Tue Apr 19 05:06:34 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 01453E06A7 for ; Tue, 19 Apr 2011 05:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CO5rXgYUOK5U for ; Tue, 19 Apr 2011 05:06:33 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 8A32EE06DB for ; Tue, 19 Apr 2011 05:06:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QC9hQ-0007z6-Nf; Tue, 19 Apr 2011 12:06:33 +0000 Date: Tue, 19 Apr 2011 21:07:00 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-lepinski-bgpsec-overview-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 12:06:34 -0000 i support adoption From randy@psg.com Tue Apr 19 05:06:48 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B09EAE06A5 for ; Tue, 19 Apr 2011 05:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7b3O1ZV00Pb8 for ; Tue, 19 Apr 2011 05:06:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 48076E06D9 for ; Tue, 19 Apr 2011 05:06:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QC9hf-0007zI-G4; Tue, 19 Apr 2011 12:06:47 +0000 Date: Tue, 19 Apr 2011 21:07:15 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-lepinski-bgpsec-protocol-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 12:06:48 -0000 i support adoption From housley@vigilsec.com Tue Apr 19 07:19:56 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CDE16E06C0 for ; Tue, 19 Apr 2011 07:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5ej8i8GbVmG for ; Tue, 19 Apr 2011 07:19:56 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfc.amsl.com (Postfix) with ESMTP id 5D5A3E06B2 for ; Tue, 19 Apr 2011 07:19:56 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 57C0CF240DE; Tue, 19 Apr 2011 10:19:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id yZUOR4r3g93z; Tue, 19 Apr 2011 10:19:54 -0400 (EDT) Received: from [192.168.2.100] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CAB58F240DC; Tue, 19 Apr 2011 10:19:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Tue, 19 Apr 2011 10:19:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-kent-bgpsec-threats-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 14:19:56 -0000 I support SIDR WG adoption of this document. On Apr 19, 2011, at 7:26 AM, Sandra Murphy wrote: > The working group has been requested to adopt = draft-kent-bgpsec-threats-01 as a working group draft, to satisfy the = following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jun 2012 A document describing threats to the routing = system >=20 > Please respond to the list with your opinion as to whether you accept = this > draft as a working group draft and are willing to work on it. = Remember > that you do not need to accept all content in a draft to adopt, as = draft > editors are required to reflect the consensus of the working group. >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned From Internet-Drafts@ietf.org Tue Apr 19 08:00:04 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 22583E0664; Tue, 19 Apr 2011 08:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.728 X-Spam-Level: X-Spam-Status: No, score=-102.728 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeF1b3eZrgIB; Tue, 19 Apr 2011 08:00:03 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4264CE075D; Tue, 19 Apr 2011 08:00:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110419150003.26826.22898.idtracker@ietfc.amsl.com> Date: Tue, 19 Apr 2011 08:00:03 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-cp-17.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 15:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Certificate Policy (CP) for the Resource PKI (RPKI Author(s) : S. Kent, et al. Filename : draft-ietf-sidr-cp-17.txt Pages : 43 Date : 2011-04-18 This document describes the certificate policy for a Public Key Infrastructure (PKI) used to support attestations about Internet Number Resource (INR) holdings. Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a (public key) certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-cp-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-19074718.I-D@ietf.org> --NextPart-- From wwwrun@ietfc.amsl.com Tue Apr 19 09:09:34 2011 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id E35B9E0754; Tue, 19 Apr 2011 09:09:34 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110419160934.E35B9E0754@ietfc.amsl.com> Date: Tue, 19 Apr 2011 09:09:34 -0700 (PDT) Cc: morrowc@ops-netman.net, Sandra.Murphy@sparta.com, sidr@ietf.org Subject: [sidr] WG Action: RECHARTER: Secure Inter-Domain Routing (sidr) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:09:35 -0000 The Secure Inter-Domain Routing (sidr) working group in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Secure Inter-Domain Routing (sidr) --------------------------------------------------- Current Status: Active Working Group Chairs: Sandra Murphy Chris Morrow Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Mailing lists: Address: sidr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sidr Archive: http://www.ietf.org/mail-archive/web/sidr Description of Working Group: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the route the same as the path through which the NLRI traveled The SIDR working group will take practical deployability into consideration. Building upon the already completed and implemented framework: * Resource Public Key Infrastructure (RPKI) * Distribution of RPKI data to routing devices and its use in operational networks * Document the use of certification objects within the secure routing architecture This working group will specify security enhancements for inter-domain routing protocols. The SIDR working group is charged with the following goals and milestones: Goals and Milestones: ID Date Pub Date Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation Mar 2011 Jun 2012 A document describing threats to the routing system Mar 2011 Jun 2012 A requirements document that addresses these threats Mar 2011 Jan 2012 Document the BGP protocol enhancements that meet the security requirements Nov 2010 Jul 2011 draft-ietf-sidr-origin-ops Mar 2011 Jul 2012 Operational deployment guidance for network operators Jun 2011 Dec 2011 System and architecture design choices made in the protocol and RPKI Mar 2010 Mar 2012 draft-ietf-sidr-cps-irs Mar 2010 Mar 2012 draft-ietf-sidr-cps-isp Nov 2010 Jan 2012 draft-ietf-sidr-pfx-validate Jan 2010 Jun 2011 draft-ietf-sidr-publication Nov 2010 Jun 2011 draft-ietf-sidr-repos-struct Nov 2010 Jun 2011 draft-ietf-sidr-roa-format Feb 2011 Jun 2011 draft-ietf-sidr-rpki-rtr Nov 2010 Nov 2011 draft-ietf-sidr-ltamgmt Dec 2010 Oct 2011 draft-rgaglian-sidr-algorithm-agility May 2011 Dec 2011 draft-ietf-sidr-usecases Jan 2011 Oct 2011 draft-ietf-sidr-ghostbusters Jan 2010 Dec 2011 draft-ietf-sidr-keyroll Jan 2010 May 2011 draft-ietf-sidr-arch Jan 2010 May 2011 draft-ietf-sidr-cp Jan 2010 May 2011 draft-ietf-sidr-res-certs Jan 2010 Jun 2011 draft-ietf-sidr-roa-validation Jan 2010 Jun 2011 draft-ietf-sidr-signed-object Jan 2010 Jun 2011 draft-ietf-sidr-rpki-manifests Jan 2010 Jul 2011 draft-ietf-sidr-rpki-algs Jan 2010 Jul 2011 draft-ietf-sidr-rescerts-provisioning Jan 2010 Aug 2011 draft-ietf-sidr-ta From sra@hactrn.net Tue Apr 19 10:30:40 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9FC40E07B2 for ; Tue, 19 Apr 2011 10:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGPJf+u7QqLv for ; Tue, 19 Apr 2011 10:30:40 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfc.amsl.com (Postfix) with ESMTP id F1CCFE06DE for ; Tue, 19 Apr 2011 10:30:39 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 6C1F928464; Tue, 19 Apr 2011 17:30:37 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3A3B322829; Tue, 19 Apr 2011 13:30:37 -0400 (EDT) Date: Tue, 19 Apr 2011 13:30:37 -0400 From: Rob Austein To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110419173037.3A3B322829@thrintun.hactrn.net> Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-kent-bgpsec-threats-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:30:40 -0000 At Tue, 19 Apr 2011 07:26:02 -0400 (Eastern Daylight Time), Sandy Murphy wrote: > > Mar 2011 Jun 2012 A document describing threats to the routing system I support adoption. From sra@hactrn.net Tue Apr 19 10:31:22 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 87577E07B2 for ; Tue, 19 Apr 2011 10:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kb1ra8H4pKXB for ; Tue, 19 Apr 2011 10:31:22 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfc.amsl.com (Postfix) with ESMTP id F3FA3E06DE for ; Tue, 19 Apr 2011 10:31:21 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 3C9AE28464; Tue, 19 Apr 2011 17:31:21 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 114A422829; Tue, 19 Apr 2011 13:31:21 -0400 (EDT) Date: Tue, 19 Apr 2011 13:31:21 -0400 From: Rob Austein To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110419173121.114A422829@thrintun.hactrn.net> Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-ymbk-bgpsec-reqs-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:31:22 -0000 At Tue, 19 Apr 2011 07:27:43 -0400 (Eastern Daylight Time), Sandy Murphy wrote: > > Mar 2011 Jun 2012 A requirements document that addresses these threats I support adoption. From sra@hactrn.net Tue Apr 19 10:32:50 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7619BE0818 for ; Tue, 19 Apr 2011 10:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHnMBizF4UfN for ; Tue, 19 Apr 2011 10:32:50 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfc.amsl.com (Postfix) with ESMTP id D1F76E07B2 for ; Tue, 19 Apr 2011 10:32:49 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 16EE928464; Tue, 19 Apr 2011 17:32:49 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id DF5DE22829; Tue, 19 Apr 2011 13:32:48 -0400 (EDT) Date: Tue, 19 Apr 2011 13:32:48 -0400 From: Rob Austein To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110419173248.DF5DE22829@thrintun.hactrn.net> Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-lepinski-bgpsec-overview-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:32:50 -0000 At Tue, 19 Apr 2011 07:29:06 -0400 (Eastern Daylight Time), Sandy Murphy wrote: > > Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes > required for origin and path validation I support adoption. From sra@hactrn.net Tue Apr 19 10:33:34 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B3724E082D for ; Tue, 19 Apr 2011 10:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDzLgNoowdRD for ; Tue, 19 Apr 2011 10:33:34 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfc.amsl.com (Postfix) with ESMTP id BD370E082C for ; Tue, 19 Apr 2011 10:33:31 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 0443A28464; Tue, 19 Apr 2011 17:33:31 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id CCA6F22829; Tue, 19 Apr 2011 13:33:30 -0400 (EDT) Date: Tue, 19 Apr 2011 13:33:30 -0400 From: Rob Austein To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110419173330.CCA6F22829@thrintun.hactrn.net> Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-lepinski-bgpsec-protocol-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:33:34 -0000 At Tue, 19 Apr 2011 07:30:08 -0400 (Eastern Daylight Time), Sandy Murphy wrote: > > Mar 2011 Jan 2012 Document the BGP protocol enhancements that meet > the security requirements I support adoption. From sra@hactrn.net Tue Apr 19 10:34:06 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0AD59E0707 for ; Tue, 19 Apr 2011 10:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgAUPjJQyImU for ; Tue, 19 Apr 2011 10:34:05 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfc.amsl.com (Postfix) with ESMTP id C7A6CE069C for ; Tue, 19 Apr 2011 10:33:59 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 0C5972846B; Tue, 19 Apr 2011 17:33:59 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D46762282A; Tue, 19 Apr 2011 13:33:58 -0400 (EDT) Date: Tue, 19 Apr 2011 13:33:58 -0400 From: Rob Austein To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110419173358.D46762282A@thrintun.hactrn.net> Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-ymbk-bgpsec-ops-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:34:06 -0000 At Tue, 19 Apr 2011 07:30:49 -0400 (Eastern Daylight Time), Sandy Murphy wrote: > > Mar 2011 Jul 2012 Operational deployment guidance for network > operators I support adoption. From Wesley.E.George@sprint.com Tue Apr 19 13:30:42 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BC49DE087B for ; Tue, 19 Apr 2011 13:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.286 X-Spam-Level: X-Spam-Status: No, score=-5.286 tagged_above=-999 required=5 tests=[AWL=1.313, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r69ha8mxk106 for ; Tue, 19 Apr 2011 13:30:42 -0700 (PDT) Received: from VA3EHSOBE006.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfc.amsl.com (Postfix) with ESMTP id 2A1EBE0874 for ; Tue, 19 Apr 2011 13:30:42 -0700 (PDT) Received: from mail107-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.8; Tue, 19 Apr 2011 20:30:41 +0000 Received: from mail107-va3 (localhost.localdomain [127.0.0.1]) by mail107-va3-R.bigfish.com (Postfix) with ESMTP id 7045C1128143 for ; Tue, 19 Apr 2011 20:30:41 +0000 (UTC) X-SpamScore: -4 X-BigFish: VS-4(zz4015Lzz1202hzzz2fh2a8h668h839h34h64h) X-Spam-TCS-SCL: 3:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm2.corp.sprint.com; RD:smtpls2.sprint.com; EFVD:NLI Received: from mail107-va3 (localhost.localdomain [127.0.0.1]) by mail107-va3 (MessageSwitch) id 1303245041332803_16323; Tue, 19 Apr 2011 20:30:41 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.236]) by mail107-va3.bigfish.com (Postfix) with ESMTP id 4E14673804B for ; Tue, 19 Apr 2011 20:30:41 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 19 Apr 2011 20:30:40 +0000 Received: from PLSWEH05.ad.sprint.com (PLSWEH05.corp.sprint.com [144.226.251.23]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p3JKUdkc003053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 19 Apr 2011 15:30:39 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PLSWEH05.ad.sprint.com ([2002:90e2:fb17::90e2:fb17]) with mapi id 14.01.0270.001; Tue, 19 Apr 2011 15:30:36 -0500 From: "George, Wes E IV [NTK]" To: "sidr@ietf.org" Thread-Topic: BGPsec drafts Thread-Index: Acv+0KaPxzhpRdkfQraU1P+LCh4jBg== Date: Tue, 19 Apr 2011 20:30:38 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EE2C@PLSWM12A.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.22] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00ED_01CBFEAF.20BAB530" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: [sidr] BGPsec drafts X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 20:30:42 -0000 ------=_NextPart_000_00ED_01CBFEAF.20BAB530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Support WG adoption of ymbk, bgpsec-overview, and bgpsec-protocol Thanks, Wes George ------=_NextPart_000_00ED_01CBFEAF.20BAB530 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxOTIw MzA0M1owIwYJKoZIhvcNAQkEMRYEFN4I686tmN/rD3JqbEJOwqS9BqadMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgK/zUBTcoXuSPt3tDyLDVMWxHXM/2+sEZA+Bj3o91PUn90hYMcm1/ENLZKZ8LJUUa5i3 Tz+69nUFcI/MolVLNo/hFfXP1x0h3tNUMErLfstHpTmWr9d5I8bUJ49QrmiRFcmS/H+4TW1ZGr+m MT+fba7X3lWxTC3kCsasMjdhXBaQAAAAAAAA ------=_NextPart_000_00ED_01CBFEAF.20BAB530-- From Wesley.E.George@sprint.com Tue Apr 19 13:59:20 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 90B04E0808 for ; Tue, 19 Apr 2011 13:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvXXv5VbA+Td for ; Tue, 19 Apr 2011 13:59:20 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfc.amsl.com (Postfix) with ESMTP id DACCFE0713 for ; Tue, 19 Apr 2011 13:59:19 -0700 (PDT) Received: from mail14-ch1-R.bigfish.com (216.32.181.168) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.8; Tue, 19 Apr 2011 20:59:19 +0000 Received: from mail14-ch1 (localhost.localdomain [127.0.0.1]) by mail14-ch1-R.bigfish.com (Postfix) with ESMTP id 134BB18B82DE for ; Tue, 19 Apr 2011 20:59:19 +0000 (UTC) X-SpamScore: -36 X-BigFish: VS-36(zz9371O542M4015Lzz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI Received: from mail14-ch1 (localhost.localdomain [127.0.0.1]) by mail14-ch1 (MessageSwitch) id 1303246758907975_5498; Tue, 19 Apr 2011 20:59:18 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail14-ch1.bigfish.com (Postfix) with ESMTP id D209B1C50050 for ; Tue, 19 Apr 2011 20:59:18 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 19 Apr 2011 20:59:16 +0000 Received: from PDAWEH03.ad.sprint.com (PDAWEH03.corp.sprint.com [144.226.110.91]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p3JKxF20001592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 19 Apr 2011 15:59:16 -0500 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH03.ad.sprint.com ([2002:90e2:6e5b::90e2:6e5b]) with mapi id 14.01.0270.001; Tue, 19 Apr 2011 15:59:18 -0500 From: "George, Wes E IV [NTK]" To: "sidr@ietf.org" Thread-Topic: BGPsec drafts Thread-Index: Acv+0KaPxzhpRdkfQraU1P+LCh4jBgAA+1bQ Date: Tue, 19 Apr 2011 20:59:14 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EEEC@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EE2C@PLSWM12A.ad.sprint.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C7EE2C@PLSWM12A.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.22] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0112_01CBFEB3.220F24D0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: Re: [sidr] BGPsec drafts X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 20:59:20 -0000 ------=_NextPart_000_0112_01CBFEB3.220F24D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Also support adoption of the threats doc. Forgot that one. -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of George, Wes E IV [NTK] Sent: Tuesday, April 19, 2011 4:31 PM To: sidr@ietf.org Subject: [sidr] BGPsec drafts Support WG adoption of ymbk, bgpsec-overview, and bgpsec-protocol Thanks, Wes George ------=_NextPart_000_0112_01CBFEB3.220F24D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxOTIw NTkyM1owIwYJKoZIhvcNAQkEMRYEFBjH8cBobGXRkQgzlsEKEG5LeclEMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgHRGCRvKH5rFcFuI2MeLXub3hBpeBhcAwSQLdy/Db66XshxJQygC09VRlNIcGSg8CITa /BThIm7MbMwCuPNMgAZWJ1s16gsxdPUPQKin9mumaukGzpW8XJJWCoqxwqjv5lQHhD4rjS/L/fhX CiWsTC8v3u1la2//sII1mq35B9/sAAAAAAAA ------=_NextPart_000_0112_01CBFEB3.220F24D0-- From wwwrun@ietfc.amsl.com Tue Apr 19 14:34:16 2011 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id 44A58E07E8; Tue, 19 Apr 2011 14:34:16 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110419213416.44A58E07E8@ietfc.amsl.com> Date: Tue, 19 Apr 2011 14:34:16 -0700 (PDT) Cc: morrowc@ops-netman.net, Sandra.Murphy@sparta.com, sidr@ietf.org Subject: [sidr] Corrected WG Action: RECHARTER: Secure Inter-Domain Routing (sidr) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 21:34:16 -0000 The Secure Inter-Domain Routing (sidr) working group in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Secure Inter-Domain Routing (sidr) --------------------------------------------------- Current Status: Active Working Group Chairs: Sandra Murphy Chris Morrow Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Technical Advisor: Steven Bellovin Mailing lists: Address: sidr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sidr Archive: http://www.ietf.org/mail-archive/web/sidr Description of Working Group: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the route the same as the path through which the NLRI traveled The SIDR working group will take practical deployability into consideration. Building upon the already completed and implemented framework: * Resource Public Key Infrastructure (RPKI) * Distribution of RPKI data to routing devices and its use in operational networks * Document the use of certification objects within the secure routing architecture This working group will specify security enhancements for inter-domain routing protocols. The SIDR working group is charged with the following goals and milestones: Goals and Milestones: ID Date Pub Date Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation Mar 2011 Jun 2012 A document describing threats to the routing system Mar 2011 Jun 2012 A requirements document that addresses these threats Mar 2011 Jan 2012 Document the BGP protocol enhancements that meet the security requirements Nov 2010 Jul 2011 draft-ietf-sidr-origin-ops Mar 2011 Jul 2012 Operational deployment guidance for network operators Jun 2011 Dec 2011 System and architecture design choices made in the protocol and RPKI Mar 2010 Mar 2012 draft-ietf-sidr-cps-irs Mar 2010 Mar 2012 draft-ietf-sidr-cps-isp Nov 2010 Jan 2012 draft-ietf-sidr-pfx-validate Jan 2010 Jun 2011 draft-ietf-sidr-publication Nov 2010 Jun 2011 draft-ietf-sidr-repos-struct Nov 2010 Jun 2011 draft-ietf-sidr-roa-format Feb 2011 Jun 2011 draft-ietf-sidr-rpki-rtr Nov 2010 Nov 2011 draft-ietf-sidr-ltamgmt Dec 2010 Oct 2011 draft-rgaglian-sidr-algorithm-agility May 2011 Dec 2011 draft-ietf-sidr-usecases Jan 2011 Oct 2011 draft-ietf-sidr-ghostbusters Jan 2010 Dec 2011 draft-ietf-sidr-keyroll Jan 2010 May 2011 draft-ietf-sidr-arch Jan 2010 May 2011 draft-ietf-sidr-cp Jan 2010 May 2011 draft-ietf-sidr-res-certs Jan 2010 Jun 2011 draft-ietf-sidr-roa-validation Jan 2010 Jun 2011 draft-ietf-sidr-signed-object Jan 2010 Jun 2011 draft-ietf-sidr-rpki-manifests Jan 2010 Jul 2011 draft-ietf-sidr-rpki-algs Jan 2010 Jul 2011 draft-ietf-sidr-rescerts-provisioning Jan 2010 Aug 2011 draft-ietf-sidr-ta From warren@kumari.net Tue Apr 19 18:05:21 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 340C1E0780 for ; Tue, 19 Apr 2011 18:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHTNLgeyvzTH for ; Tue, 19 Apr 2011 18:05:20 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfc.amsl.com (Postfix) with ESMTP id 2AEF5E0712 for ; Tue, 19 Apr 2011 18:05:20 -0700 (PDT) Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 952E81B40982; Tue, 19 Apr 2011 21:05:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 19 Apr 2011 21:05:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-kent-bgpsec-threats-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 01:05:21 -0000 I support WG adoption of this draft (and have even read it :-P) and am = willing to review, participate in discussions, etc... W On Apr 19, 2011, at 7:26 AM, Sandra Murphy wrote: > The working group has been requested to adopt = draft-kent-bgpsec-threats-01 as a working group draft, to satisfy the = following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jun 2012 A document describing threats to the routing = system >=20 > Please respond to the list with your opinion as to whether you accept = this > draft as a working group draft and are willing to work on it. = Remember > that you do not need to accept all content in a draft to adopt, as = draft > editors are required to reflect the consensus of the working group. >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From warren@kumari.net Tue Apr 19 18:05:38 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1ED39E0780 for ; Tue, 19 Apr 2011 18:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLE9LMJOcyd0 for ; Tue, 19 Apr 2011 18:05:35 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfc.amsl.com (Postfix) with ESMTP id A8BC9E0712 for ; Tue, 19 Apr 2011 18:05:35 -0700 (PDT) Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 113521B40982; Tue, 19 Apr 2011 21:05:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 19 Apr 2011 21:05:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-ymbk-bgpsec-reqs-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 01:05:38 -0000 I support WG adoption of this draft (and have even read it :-P) and am = willing to review, participate in discussions, etc... W On Apr 19, 2011, at 7:27 AM, Sandra Murphy wrote: > The working group has been requested to adopt = draft-ymbk-bgpsec-reqs-02 as a working group draft, to satisfy the = following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jun 2012 A requirements document that addresses these = threats >=20 >=20 > Please respond to the list with your opinion as to whether you accept = this > draft as a working group draft and are willing to work on it. = Remember > that you do not need to accept all content in a draft to adopt, as = draft > editors are required to reflect the consensus of the working group. >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From warren@kumari.net Tue Apr 19 18:06:35 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DF3BDE07D9 for ; Tue, 19 Apr 2011 18:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCc-Th7V-YM7 for ; Tue, 19 Apr 2011 18:06:35 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfc.amsl.com (Postfix) with ESMTP id 5CA62E07B4 for ; Tue, 19 Apr 2011 18:06:35 -0700 (PDT) Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id AB0081B40982; Tue, 19 Apr 2011 21:06:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 19 Apr 2011 21:06:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <803DD8F4-369B-428B-B5BD-0A70D7E56A34@kumari.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-lepinski-bgpsec-overview-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 01:06:36 -0000 Strongly support adoption.... W On Apr 19, 2011, at 7:29 AM, Sandra Murphy wrote: > The working group has been requested to adopt = draft-lepinski-bgpsec-overview-00 as a working group draft, to satisfy = the following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes > required for origin and path validation >=20 > Please respond to the list with your opinion as to whether you accept = this draft as a working group draft and are willing to work on it. = Remember that you do not need to accept all content in a draft to adopt, = as draft editors are required to reflect the consensus of the working = group. >=20 >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From warren@kumari.net Tue Apr 19 18:09:31 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1C08AE07D2 for ; Tue, 19 Apr 2011 18:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XVKTY+32x2H for ; Tue, 19 Apr 2011 18:09:30 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfc.amsl.com (Postfix) with ESMTP id 4DAFBE072C for ; Tue, 19 Apr 2011 18:09:30 -0700 (PDT) Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id C61231B40982; Tue, 19 Apr 2011 21:09:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 19 Apr 2011 21:09:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <078375E7-AD0A-439B-8844-8795F4281CF5@kumari.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-lepinski-bgpsec-protocol-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 01:09:31 -0000 As a contributor I (obviously) support adoption.... (and, in case y'all couldn't tell, am getting bored of typing "I = support"...) On Apr 19, 2011, at 7:30 AM, Sandra Murphy wrote: > The working group has been requested to adopt = draft-lepinski-bgpsec-protocol-00 as a working group draft, to satisfy = the following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jan 2012 Document the BGP protocol enhancements that meet > the security requirements >=20 > Please respond to the list with your opinion as to whether you accept = this draft as a working group draft and are willing to work on it. = Remember that you do not need to accept all content in a draft to adopt, = as draft editors are required to reflect the consensus of the working = group. >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned Pictures?! W >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From warren@kumari.net Tue Apr 19 18:10:12 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AA2DEE076F for ; Tue, 19 Apr 2011 18:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnLH5256kINU for ; Tue, 19 Apr 2011 18:10:12 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfc.amsl.com (Postfix) with ESMTP id 2AD53E072C for ; Tue, 19 Apr 2011 18:10:12 -0700 (PDT) Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id B13651B40982; Tue, 19 Apr 2011 21:10:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 19 Apr 2011 21:10:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <553A82F2-B53E-4CDA-A316-3059DCD34CFD@kumari.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-ymbk-bgpsec-ops-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 01:10:12 -0000 Adoption supported!=20 W On Apr 19, 2011, at 7:30 AM, Sandra Murphy wrote: > The working group has been requested to adopt draft-ymbk-bgpsec-ops-01 = as a working group draft, to satisfy the following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jul 2012 Operational deployment guidance for network = operators >=20 >=20 > Please respond to the list with your opinion as to whether you accept = this > draft as a working group draft and are willing to work on it. = Remember > that you do not need to accept all content in a draft to adopt, as = draft > editors are required to reflect the consensus of the working group. >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From housley@vigilsec.com Wed Apr 20 07:49:23 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 26D97E0681 for ; Wed, 20 Apr 2011 07:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.403 X-Spam-Level: X-Spam-Status: No, score=-102.403 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iukJobuHByDS for ; Wed, 20 Apr 2011 07:49:22 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfc.amsl.com (Postfix) with ESMTP id AAC6AE0613 for ; Wed, 20 Apr 2011 07:49:22 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 1E94FF2411F; Wed, 20 Apr 2011 10:49:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id PODXNlagv3sx; Wed, 20 Apr 2011 10:49:18 -0400 (EDT) Received: from [192.168.2.100] (pool-71-178-218-117.washdc.fios.verizon.net [71.178.218.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A1BF2F24036; Wed, 20 Apr 2011 10:49:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Wed, 20 Apr 2011 10:49:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4B57F59E-64D4-403D-B63A-63BE2A2E6356@vigilsec.com> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] call for adoption of draft-ymbk-bgpsec-reqs-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 14:49:23 -0000 I have read this document, and I support SIDR WG adoption of this draft. Russ On Apr 19, 2011, at 7:27 AM, Sandra Murphy wrote: > The working group has been requested to adopt = draft-ymbk-bgpsec-reqs-02 as a working group draft, to satisfy the = following item on our charter: >=20 > ID Date Pub Date > Mar 2011 Jun 2012 A requirements document that addresses these = threats >=20 >=20 > Please respond to the list with your opinion as to whether you accept = this > draft as a working group draft and are willing to work on it. = Remember > that you do not need to accept all content in a draft to adopt, as = draft > editors are required to reflect the consensus of the working group. >=20 > This call will end 3 May 2011. >=20 > --Sandy, speaking as wg co-chair, with wg ceremonial garb donned >=20 From touch@isi.edu Wed Apr 20 13:29:50 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 280E4E0753 for ; Wed, 20 Apr 2011 13:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.962 X-Spam-Level: X-Spam-Status: No, score=-103.962 tagged_above=-999 required=5 tests=[AWL=1.397, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxCqPDLJ3GeV for ; Wed, 20 Apr 2011 13:29:49 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfc.amsl.com (Postfix) with ESMTP id 2EF42E0669 for ; Wed, 20 Apr 2011 13:29:49 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p3KKTEvO018447 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2011 13:29:14 -0700 (PDT) Message-ID: <4DAF421A.9060100@isi.edu> Date: Wed, 20 Apr 2011 13:29:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 20:29:50 -0000 Hi, all, I've reviewed the discussion about mandatory-to-implement connection security that dates back to Morrow's post of 1 Apr: http://www.ietf.org/mail-archive/web/sidr/current/msg02623.html I'd like to note a few things: 1) ssh does not protect the transport connection ssh is an application protocol, not a transport protocol It provides privacy and authentication at the application layer, of the data over the TCP connection, but that connection can be interrupted by an attacker. This may not have the same impact as for vanilla BGP (where the connection disappearing causes routes to be removed), but should be a consideration in a "mandatory to implement" component, IMO. 2) TCP-AO was designed for BGP TCP-AO was designed to get around concerns with the use of IPsec for BGP protection, and to correct for weaknesses in TCP MD5. Any platform that is intended to use BGP in a protected way will need to implement TCP-AO anyway. Using that mechanism to protect other parts of BGP seems appropriate. 3) TCP-AO obsoletes TCP MD5 We did not deprecate TCP MD5 for legacy reasons only. It should not be recommended in any new cases. 4) a SIDR solution assuming TCP-AO isn't available on servers is an interim only RFCs ought not focus on short term solutions, especially ones that are so easily corrected. If the issue is the lack of a TCP-AO implementation in Linux and FreeBSD, it would be more productive to find the resources (6 man-months approx.) to just write this than even to discuss it on this list at length further. If you do insist on including other alternatives, I would strongly suggest listing only IPsec; if you do include ssh (or, AFAICT, if you really want to get to servers, why not tls? surely servers are as likely if not more so to have HTTPS support) then you should note the lack of protection to the transport layer, and any implications that result. Joe From touch@isi.edu Wed Apr 20 13:41:03 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 776C1E0770 for ; Wed, 20 Apr 2011 13:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.656 X-Spam-Level: X-Spam-Status: No, score=-104.656 tagged_above=-999 required=5 tests=[AWL=1.943, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYnZOEKpDrn4 for ; Wed, 20 Apr 2011 13:41:02 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfc.amsl.com (Postfix) with ESMTP id A289DE0669 for ; Wed, 20 Apr 2011 13:41:02 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p3KKeCS0020320 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2011 13:40:12 -0700 (PDT) Message-ID: <4DAF44AC.8060408@isi.edu> Date: Wed, 20 Apr 2011 13:40:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Stephen Kent References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 20:41:03 -0000 On 4/11/2011 12:49 PM, Stephen Kent wrote: > At 9:30 PM -0700 4/6/11, Brian Weis wrote: >> On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: >> >>>> Getting a new application (such as the rtr protocol) specifying >>>> hmac-md5 mandatory to implement through a Secdir review and then the >>>> Security ADs just won't happen. The only exception I can think of is >>>> if there were no possible alternatives, and that's obviously not the >>>> case here. >>> >>> with AO not implemented on any servers, routers not having ssh >>> libraries, and this being a server to router protocol, what are the >>> alternatives? >>> >>> randy >> >> I'm surprised IPsec hasn't been mentioned in this thread ... was it >> previously discussed and rejected? Correct me if I'm wrong, but I >> believe it's common for BGP routers to support IPsec and servers >> definitely support IPsec. On the router side, one or two IPsec >> sessions to servers should not be a burden. I'm less sure of the >> server IPsec scaling properties, but I would expect a LINUX or BSD >> kernel to have the scaling issues as were discussed earlier in this >> thread regarding SSH but I'm no expert here. >> >> Brian > > A few years ago we were told by vendors that many router implementations > of IPsec were available only to traffic passing through a router, not to > the > control plane terminating in a router. Unless that has changed, IPsec is > not a good candidate here. FWIW, that was an artifact of the IPsec requirements for routers. 4301 has the following requirements: (end sec 4.1, RFC 4301): In summary, a) A host implementation of IPsec MUST support both transport and tunnel mode. This is true for native, BITS, and BITW implementations for hosts. b) A security gateway MUST support tunnel mode and MAY support transport mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management, or to provide security between two intermediate systems along a path. A gateway acts as a host for all its routing protocol connections, and thus its control plane should have to comply with (a). I agree, that's why IPsec isn't a good choice to protect BGP, but we sort of created that situation in 4301, AFAICT. Joe From bew@cisco.com Wed Apr 20 17:19:41 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6B3F0E0800 for ; Wed, 20 Apr 2011 17:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncYJccRNitvu for ; Wed, 20 Apr 2011 17:19:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 5BC58E077E for ; Wed, 20 Apr 2011 17:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=3011; q=dns/txt; s=iport; t=1303345180; x=1304554780; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+KrLe31Rz1kDK8Qd41+Pvw+Mx9GjuhPCaq8KBg0pjew=; b=hn0F5+z7+vTccZQIH9secS7q7UBxzyyVi/8vc40AiJSysVPs2PBx50qa SlW7EzSkFzDA/Ea3MLo2KLzexGTjkIbX/b6IAFuv/Ncfb6dS0zHj5k7+w f8DomYW2s5UOA+WQaZ9XWGAW3gNezGikEi+APRIBsdXdk9ywwUhh8/N5U 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJB3r02rRDoJ/2dsb2JhbAClSXeIb6FPnHiDGYJdBIV0iDCNWg X-IronPort-AV: E=Sophos;i="4.64,248,1301875200"; d="scan'208";a="433919461" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 21 Apr 2011 00:19:36 +0000 Received: from stealth-10-32-244-212.cisco.com (stealth-10-32-244-212.cisco.com [10.32.244.212]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3L0JaB8027795; Thu, 21 Apr 2011 00:19:36 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <4DAF44AC.8060408@isi.edu> Date: Wed, 20 Apr 2011 17:19:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <4DAF44AC.8060408@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:19:41 -0000 On Apr 20, 2011, at 1:40 PM, Joe Touch wrote: >=20 >=20 > On 4/11/2011 12:49 PM, Stephen Kent wrote: >> At 9:30 PM -0700 4/6/11, Brian Weis wrote: >>> On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: >>>=20 >>>>> Getting a new application (such as the rtr protocol) specifying >>>>> hmac-md5 mandatory to implement through a Secdir review and then = the >>>>> Security ADs just won't happen. The only exception I can think of = is >>>>> if there were no possible alternatives, and that's obviously not = the >>>>> case here. >>>>=20 >>>> with AO not implemented on any servers, routers not having ssh >>>> libraries, and this being a server to router protocol, what are the >>>> alternatives? >>>>=20 >>>> randy >>>=20 >>> I'm surprised IPsec hasn't been mentioned in this thread ... was it >>> previously discussed and rejected? Correct me if I'm wrong, but I >>> believe it's common for BGP routers to support IPsec and servers >>> definitely support IPsec. On the router side, one or two IPsec >>> sessions to servers should not be a burden. I'm less sure of the >>> server IPsec scaling properties, but I would expect a LINUX or BSD >>> kernel to have the scaling issues as were discussed earlier in this >>> thread regarding SSH but I'm no expert here. >>>=20 >>> Brian >>=20 >> A few years ago we were told by vendors that many router = implementations >> of IPsec were available only to traffic passing through a router, not = to >> the >> control plane terminating in a router. Unless that has changed, IPsec = is >> not a good candidate here. >=20 > FWIW, that was an artifact of the IPsec requirements for routers. 4301 = has the following requirements: >=20 > (end sec 4.1, RFC 4301): > In summary, >=20 > a) A host implementation of IPsec MUST support both transport and > tunnel mode. This is true for native, BITS, and BITW > implementations for hosts. >=20 > b) A security gateway MUST support tunnel mode and MAY support > transport mode. If it supports transport mode, that should be > used only when the security gateway is acting as a host, e.g., = for > network management, or to provide security between two > intermediate systems along a path. >=20 > A gateway acts as a host for all its routing protocol connections, and = thus its control plane should have to comply with (a). >=20 > I agree, that's why IPsec isn't a good choice to protect BGP, but we = sort of created that situation in 4301, AFAICT. >=20 > Joe I won't quibble with that argument as far as protecting BGP. But for the = "router-to-server" protocol described by this draft is actually acting = as a host for the exchange. There are more router IPsec implementations = that can protect the control plane now, and meeting the requirements = above would likely be doable. Brian --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From touch@isi.edu Wed Apr 20 17:25:24 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A967BE07D7 for ; Wed, 20 Apr 2011 17:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.753 X-Spam-Level: X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er-6zh4rJEkD for ; Wed, 20 Apr 2011 17:25:23 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfc.amsl.com (Postfix) with ESMTP id B2F62E077E for ; Wed, 20 Apr 2011 17:25:23 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p3L0PGoF006268 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2011 17:25:16 -0700 (PDT) Message-ID: <4DAF796C.7010807@isi.edu> Date: Wed, 20 Apr 2011 17:25:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Weis References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <4DAF44AC.8060408@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p3L0PGoF006268 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:25:24 -0000 On 4/20/2011 5:19 PM, Brian Weis wrote: > > On Apr 20, 2011, at 1:40 PM, Joe Touch wrote: > >> >> >> On 4/11/2011 12:49 PM, Stephen Kent wrote: >>> At 9:30 PM -0700 4/6/11, Brian Weis wrote: >>>> On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: >>>> >>>>>> Getting a new application (such as the rtr protocol) >>>>>> specifying hmac-md5 mandatory to implement through a Secdir >>>>>> review and then the Security ADs just won't happen. The >>>>>> only exception I can think of is if there were no possible >>>>>> alternatives, and that's obviously not the case here. >>>>> >>>>> with AO not implemented on any servers, routers not having >>>>> ssh libraries, and this being a server to router protocol, >>>>> what are the alternatives? >>>>> >>>>> randy >>>> >>>> I'm surprised IPsec hasn't been mentioned in this thread ... >>>> was it previously discussed and rejected? Correct me if I'm >>>> wrong, but I believe it's common for BGP routers to support >>>> IPsec and servers definitely support IPsec. On the router side, >>>> one or two IPsec sessions to servers should not be a burden. >>>> I'm less sure of the server IPsec scaling properties, but I >>>> would expect a LINUX or BSD kernel to have the scaling issues >>>> as were discussed earlier in this thread regarding SSH but I'm >>>> no expert here. >>>> >>>> Brian >>> >>> A few years ago we were told by vendors that many router >>> implementations of IPsec were available only to traffic passing >>> through a router, not to the control plane terminating in a >>> router. Unless that has changed, IPsec is not a good candidate >>> here. >> >> FWIW, that was an artifact of the IPsec requirements for routers. >> 4301 has the following requirements: >> >> (end sec 4.1, RFC 4301): In summary, >> >> a) A host implementation of IPsec MUST support both transport and >> tunnel mode. This is true for native, BITS, and BITW >> implementations for hosts. >> >> b) A security gateway MUST support tunnel mode and MAY support >> transport mode. If it supports transport mode, that should be used >> only when the security gateway is acting as a host, e.g., for >> network management, or to provide security between two intermediate >> systems along a path. >> >> A gateway acts as a host for all its routing protocol connections, >> and thus its control plane should have to comply with (a). >> >> I agree, that's why IPsec isn't a good choice to protect BGP, but >> we sort of created that situation in 4301, AFAICT. >> >> Joe > > I won't quibble with that argument as far as protecting BGP. But for > the "router-to-server" protocol described by this draft is actually > acting as a host for the exchange. Routers act as hosts for all routing protocol exchanges; that's not unique to the router-server exchange. > There are more router IPsec implementations that can protect the > control plane now, and meeting the requirements above would likely be > doable. There are other potential reasons why IPsec may or may not be the best choice, but I don't much care whether IPsec or TCP-AO is used; those are the appropriate choices if you care that the transport protocol is protected. Joe From christopher.morrow@gmail.com Thu Apr 21 19:45:12 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CD9C2E0753 for ; Thu, 21 Apr 2011 19:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0Lx28gKxqVc for ; Thu, 21 Apr 2011 19:45:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id B1050E06E2 for ; Thu, 21 Apr 2011 19:45:11 -0700 (PDT) Received: by wyb29 with SMTP id 29so228269wyb.31 for ; Thu, 21 Apr 2011 19:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c3426nKt04rwV/RJDbv6JD4zVlfjcmOtBCFQMqjplwo=; b=ZhEx7a2+rIGdULDcqdfgSxXKfppLU+jVdlaCB/oybJ6iSbGTOmVV1pbNq90vzgcARV aTKMFdE/06B5Zc2tLG6sic0c7UX/RzY3pj9M0JHBGxvuOoPVYPHZkoe/+hxxcXbToPiP EsxJ6f9lL+5Zp58refSK9dNd7eQacjBfwSLE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=FpDSuYITfbQ3Pull5zlKZ3iGAJ/Dsdhac4S2JvTcKPYO4BqlKkFHaipPbojwo1eflN h5JQi3CTxidgCRtSGAgHQoFCWBZBUj3nbeK/wBDPg2K+JWP9NjkmBfAXUuDZjJo/ot+E 3EG/mlW+eCePEZSlnRFbQvGm/KbCBthrBFQbY= MIME-Version: 1.0 Received: by 10.216.9.141 with SMTP id 13mr180410wet.73.1303440310781; Thu, 21 Apr 2011 19:45:10 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.234.156 with HTTP; Thu, 21 Apr 2011 19:45:10 -0700 (PDT) In-Reply-To: <4DAF796C.7010807@isi.edu> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> Date: Thu, 21 Apr 2011 22:45:10 -0400 X-Google-Sender-Auth: QRSBH7hK8E0rXFKUuHZz5G1zyXA Message-ID: From: Christopher Morrow To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 02:45:13 -0000 So.. round and round the rosemary bush we go, still we have no actual things that run actual tcp-ao, so given that can we either: 1) use md5 (as a MUST, with ssh as a MAY) and rev the doc at a later point to say that AO is a MUST and remove md5 2) move this doc along the path 3) get implementations of the protocol today to start using md5 -chris (co-chair-toe-socks-on) On Wed, Apr 20, 2011 at 8:25 PM, Joe Touch wrote: > > > On 4/20/2011 5:19 PM, Brian Weis wrote: >> >> On Apr 20, 2011, at 1:40 PM, Joe Touch wrote: >> >>> >>> >>> On 4/11/2011 12:49 PM, Stephen Kent wrote: >>>> >>>> At 9:30 PM -0700 4/6/11, Brian Weis wrote: >>>>> >>>>> On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: >>>>> >>>>>>> Getting a new application (such as the rtr protocol) >>>>>>> specifying hmac-md5 mandatory to implement through a Secdir >>>>>>> review and then the Security ADs just won't happen. The >>>>>>> only exception I can think of is if there were no possible >>>>>>> alternatives, and that's obviously not the case here. >>>>>> >>>>>> with AO not implemented on any servers, routers not having >>>>>> ssh libraries, and this being a server to router protocol, >>>>>> what are the alternatives? >>>>>> >>>>>> randy >>>>> >>>>> I'm surprised IPsec hasn't been mentioned in this thread ... >>>>> was it previously discussed and rejected? Correct me if I'm >>>>> wrong, but I believe it's common for BGP routers to support >>>>> IPsec and servers definitely support IPsec. On the router side, >>>>> one or two IPsec sessions to servers should not be a burden. >>>>> I'm less sure of the server IPsec scaling properties, but I >>>>> would expect a LINUX or BSD kernel to have the scaling issues >>>>> as were discussed earlier in this thread regarding SSH but I'm >>>>> no expert here. >>>>> >>>>> Brian >>>> >>>> A few years ago we were told by vendors that many router >>>> implementations of IPsec were available only to traffic passing >>>> through a router, not to the control plane terminating in a >>>> router. Unless that has changed, IPsec is not a good candidate >>>> here. >>> >>> FWIW, that was an artifact of the IPsec requirements for routers. >>> 4301 has the following requirements: >>> >>> (end sec 4.1, RFC 4301): In summary, >>> >>> a) A host implementation of IPsec MUST support both transport and >>> tunnel mode. =A0This is true for native, BITS, and BITW >>> implementations for hosts. >>> >>> b) A security gateway MUST support tunnel mode and MAY support >>> transport mode. =A0If it supports transport mode, that should be used >>> only when the security gateway is acting as a host, e.g., for >>> network management, or to provide security between two intermediate >>> systems along a path. >>> >>> A gateway acts as a host for all its routing protocol connections, >>> and thus its control plane should have to comply with (a). >>> >>> I agree, that's why IPsec isn't a good choice to protect BGP, but >>> we sort of created that situation in 4301, AFAICT. >>> >>> Joe >> >> I won't quibble with that argument as far as protecting BGP. But for >> the "router-to-server" protocol described by this draft is actually >> acting as a host for the exchange. > > Routers act as hosts for all routing protocol exchanges; that's not uniqu= e > to the router-server exchange. > >> There are more router IPsec implementations that can protect the >> control plane now, and meeting the requirements above would likely be >> doable. > > There are other potential reasons why IPsec may or may not be the best > choice, but I don't much care whether IPsec or TCP-AO is used; those are = the > appropriate choices if you care that the transport protocol is protected. > > Joe > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Thu Apr 21 21:06:14 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C359DE07C5 for ; Thu, 21 Apr 2011 21:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoaRiQI9xjU4 for ; Thu, 21 Apr 2011 21:06:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id 26A22E07C1 for ; Thu, 21 Apr 2011 21:06:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QD7dD-000MKZ-SH; Fri, 22 Apr 2011 04:06:12 +0000 Date: Fri, 22 Apr 2011 13:06:46 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 04:06:14 -0000 > 1) use md5 (as a MUST, with ssh as a MAY) and rev the doc at a later > point to say that AO is a MUST and remove md5 > 2) move this doc along the path > 3) get implementations of the protocol today to start using md5 the base problem is a conflict between having and liking running code and that the transport coverage is not what we would want in the long run. we now have running code from all major players in the game (junos, ios, and ios/xr) which use cleartext. while this is clearly not desirable, we wanted running code while the ietf did rinse repeat for as long as amused it. and we have cleartext server code on many unix and unix-wannabe platforms. there is also ssh server code on thos platforms. one of the three major vendor platforms is testing ssh now. the others are probably hoping this ssh thing will go away. :) in 2012, we will probably see AO on most router platforms. this will be driven as much or more by bgp's needs as rpki-rtr's. unfortunately, server implementations are likely to trickle in more slowly. so, in the long run, we can do the 'right' thing, presuming fashions do not change. but, in the meantime, running code trumps. so the doc will probably stay as it is, most stuff will run over cleartext as ssh will be slowly deploying. next rev, we can go AO as mandatory. no, i do not like this. but i am running the validation stuff and am not writing code, so i ain't complainin' too much. randy From touch@isi.edu Thu Apr 21 21:16:12 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F2DF1E07C0 for ; Thu, 21 Apr 2011 21:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.161 X-Spam-Level: X-Spam-Status: No, score=-104.161 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2lTVz9PITWI for ; Thu, 21 Apr 2011 21:16:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfc.amsl.com (Postfix) with ESMTP id E3052E06DD for ; Thu, 21 Apr 2011 21:16:10 -0700 (PDT) Received: from [192.168.1.94] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p3M4ExAb003543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Apr 2011 21:15:08 -0700 (PDT) References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8H7) Content-Type: text/plain; charset=us-ascii Message-Id: <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8H7) From: Joe Touch Date: Thu, 21 Apr 2011 21:14:57 -0700 To: Christopher Morrow X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 04:16:12 -0000 On Apr 21, 2011, at 7:45 PM, Christopher Morrow wr= ote: > So.. round and round the rosemary bush we go, still we have no actual > things that run actual tcp-ao, so given that can we either: >=20 > 1) use md5 (as a MUST, with ssh as a MAY) and rev the doc at a later > point to say that AO is a MUST and remove md5 > 2) move this doc along the path > 3) get implementations of the protocol today to start using md5 You could instead do what the TCP-AO rfc recommends for apps like BGP: - MUST support TCP-AO - MAY also support TCP MD5 for backward compatibility This avoids reinventing an answer for BGP caches and just applies the *curre= nt* advice for BGP in general.=20 Joe >=20 > -chris > (co-chair-toe-socks-on) >=20 > On Wed, Apr 20, 2011 at 8:25 PM, Joe Touch wrote: >>=20 >>=20 >> On 4/20/2011 5:19 PM, Brian Weis wrote: >>>=20 >>> On Apr 20, 2011, at 1:40 PM, Joe Touch wrote: >>>=20 >>>>=20 >>>>=20 >>>> On 4/11/2011 12:49 PM, Stephen Kent wrote: >>>>>=20 >>>>> At 9:30 PM -0700 4/6/11, Brian Weis wrote: >>>>>>=20 >>>>>> On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: >>>>>>=20 >>>>>>>> Getting a new application (such as the rtr protocol) >>>>>>>> specifying hmac-md5 mandatory to implement through a Secdir >>>>>>>> review and then the Security ADs just won't happen. The >>>>>>>> only exception I can think of is if there were no possible >>>>>>>> alternatives, and that's obviously not the case here. >>>>>>>=20 >>>>>>> with AO not implemented on any servers, routers not having >>>>>>> ssh libraries, and this being a server to router protocol, >>>>>>> what are the alternatives? >>>>>>>=20 >>>>>>> randy >>>>>>=20 >>>>>> I'm surprised IPsec hasn't been mentioned in this thread ... >>>>>> was it previously discussed and rejected? Correct me if I'm >>>>>> wrong, but I believe it's common for BGP routers to support >>>>>> IPsec and servers definitely support IPsec. On the router side, >>>>>> one or two IPsec sessions to servers should not be a burden. >>>>>> I'm less sure of the server IPsec scaling properties, but I >>>>>> would expect a LINUX or BSD kernel to have the scaling issues >>>>>> as were discussed earlier in this thread regarding SSH but I'm >>>>>> no expert here. >>>>>>=20 >>>>>> Brian >>>>>=20 >>>>> A few years ago we were told by vendors that many router >>>>> implementations of IPsec were available only to traffic passing >>>>> through a router, not to the control plane terminating in a >>>>> router. Unless that has changed, IPsec is not a good candidate >>>>> here. >>>>=20 >>>> FWIW, that was an artifact of the IPsec requirements for routers. >>>> 4301 has the following requirements: >>>>=20 >>>> (end sec 4.1, RFC 4301): In summary, >>>>=20 >>>> a) A host implementation of IPsec MUST support both transport and >>>> tunnel mode. This is true for native, BITS, and BITW >>>> implementations for hosts. >>>>=20 >>>> b) A security gateway MUST support tunnel mode and MAY support >>>> transport mode. If it supports transport mode, that should be used >>>> only when the security gateway is acting as a host, e.g., for >>>> network management, or to provide security between two intermediate >>>> systems along a path. >>>>=20 >>>> A gateway acts as a host for all its routing protocol connections, >>>> and thus its control plane should have to comply with (a). >>>>=20 >>>> I agree, that's why IPsec isn't a good choice to protect BGP, but >>>> we sort of created that situation in 4301, AFAICT. >>>>=20 >>>> Joe >>>=20 >>> I won't quibble with that argument as far as protecting BGP. But for >>> the "router-to-server" protocol described by this draft is actually >>> acting as a host for the exchange. >>=20 >> Routers act as hosts for all routing protocol exchanges; that's not uniqu= e >> to the router-server exchange. >>=20 >>> There are more router IPsec implementations that can protect the >>> control plane now, and meeting the requirements above would likely be >>> doable. >>=20 >> There are other potential reasons why IPsec may or may not be the best >> choice, but I don't much care whether IPsec or TCP-AO is used; those are t= he >> appropriate choices if you care that the transport protocol is protected.= >>=20 >> Joe >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 From christopher.morrow@gmail.com Thu Apr 21 22:10:18 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AA4B7E078E for ; Thu, 21 Apr 2011 22:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1opIPXDkaoK for ; Thu, 21 Apr 2011 22:10:17 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 814A1E07A7 for ; Thu, 21 Apr 2011 22:10:17 -0700 (PDT) Received: by wwa36 with SMTP id 36so246116wwa.13 for ; Thu, 21 Apr 2011 22:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=okNhJGYbywcsRHLVtO/vM54f/CO9ekX576wKn3MVQP4=; b=Xnfc+FqaPUcPNnIGNaTSoEv85jS1eWF/jsZSHRTjFArziqe3IqeSMGRWOwH0Nwx3yH kC2l9IDjT+HVy57A68nu5YIKc5CxOyKkbOgHDn5rODnyqMwPN/g1GZB7HvrpSgZJA2UM pWOMX2lbZbp9O40D/HGopmYQja5X2SVFpWR2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tItUbZbd91CuXJMhIAgBVm12mLJFB4gPEt+ccNzN83dpXVw5VVO/bWaBw+rbnVG5l5 mNoAfQoYsXjVeBfq5U7wPFdUm0JqQptG0J7fdtYH3xjZc9Xi2bSdaTcA3AnGoECrwLuw pSZAvfEC2EcbvYMh+Kz3VYVZ99q6uKSiejecA= MIME-Version: 1.0 Received: by 10.216.69.203 with SMTP id n53mr274144wed.88.1303449016694; Thu, 21 Apr 2011 22:10:16 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.234.156 with HTTP; Thu, 21 Apr 2011 22:10:16 -0700 (PDT) In-Reply-To: <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> Date: Fri, 22 Apr 2011 01:10:16 -0400 X-Google-Sender-Auth: 76WxLZNjRRWc9zeV5WoeyYsoUHY Message-ID: From: Christopher Morrow To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 05:10:18 -0000 On Fri, Apr 22, 2011 at 12:14 AM, Joe Touch wrote: > > > On Apr 21, 2011, at 7:45 PM, Christopher Morrow = wrote: > >> So.. round and round the rosemary bush we go, still we have no actual >> things that run actual tcp-ao, so given that can we either: >> >> 1) use md5 (as a MUST, with ssh as a MAY) and rev the doc at a later >> point to say that AO is a MUST and remove md5 >> 2) move this doc along the path >> 3) get implementations of the protocol today to start using md5 > > You could instead do what the TCP-AO rfc recommends for apps like BGP: > > - MUST support TCP-AO > - MAY also support TCP MD5 for backward compatibility > > This avoids reinventing an answer for BGP caches and just applies the *cu= rrent* advice for BGP in general. > bgp cache is not bgp... it's really just a random tcp session from a router to a thing some where else. (does that change your proposed above?) -Chris > Joe > > >> >> -chris >> (co-chair-toe-socks-on) >> >> On Wed, Apr 20, 2011 at 8:25 PM, Joe Touch wrote: >>> >>> >>> On 4/20/2011 5:19 PM, Brian Weis wrote: >>>> >>>> On Apr 20, 2011, at 1:40 PM, Joe Touch wrote: >>>> >>>>> >>>>> >>>>> On 4/11/2011 12:49 PM, Stephen Kent wrote: >>>>>> >>>>>> At 9:30 PM -0700 4/6/11, Brian Weis wrote: >>>>>>> >>>>>>> On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: >>>>>>> >>>>>>>>> Getting a new application (such as the rtr protocol) >>>>>>>>> specifying hmac-md5 mandatory to implement through a Secdir >>>>>>>>> review and then the Security ADs just won't happen. The >>>>>>>>> only exception I can think of is if there were no possible >>>>>>>>> alternatives, and that's obviously not the case here. >>>>>>>> >>>>>>>> with AO not implemented on any servers, routers not having >>>>>>>> ssh libraries, and this being a server to router protocol, >>>>>>>> what are the alternatives? >>>>>>>> >>>>>>>> randy >>>>>>> >>>>>>> I'm surprised IPsec hasn't been mentioned in this thread ... >>>>>>> was it previously discussed and rejected? Correct me if I'm >>>>>>> wrong, but I believe it's common for BGP routers to support >>>>>>> IPsec and servers definitely support IPsec. On the router side, >>>>>>> one or two IPsec sessions to servers should not be a burden. >>>>>>> I'm less sure of the server IPsec scaling properties, but I >>>>>>> would expect a LINUX or BSD kernel to have the scaling issues >>>>>>> as were discussed earlier in this thread regarding SSH but I'm >>>>>>> no expert here. >>>>>>> >>>>>>> Brian >>>>>> >>>>>> A few years ago we were told by vendors that many router >>>>>> implementations of IPsec were available only to traffic passing >>>>>> through a router, not to the control plane terminating in a >>>>>> router. Unless that has changed, IPsec is not a good candidate >>>>>> here. >>>>> >>>>> FWIW, that was an artifact of the IPsec requirements for routers. >>>>> 4301 has the following requirements: >>>>> >>>>> (end sec 4.1, RFC 4301): In summary, >>>>> >>>>> a) A host implementation of IPsec MUST support both transport and >>>>> tunnel mode. =A0This is true for native, BITS, and BITW >>>>> implementations for hosts. >>>>> >>>>> b) A security gateway MUST support tunnel mode and MAY support >>>>> transport mode. =A0If it supports transport mode, that should be used >>>>> only when the security gateway is acting as a host, e.g., for >>>>> network management, or to provide security between two intermediate >>>>> systems along a path. >>>>> >>>>> A gateway acts as a host for all its routing protocol connections, >>>>> and thus its control plane should have to comply with (a). >>>>> >>>>> I agree, that's why IPsec isn't a good choice to protect BGP, but >>>>> we sort of created that situation in 4301, AFAICT. >>>>> >>>>> Joe >>>> >>>> I won't quibble with that argument as far as protecting BGP. But for >>>> the "router-to-server" protocol described by this draft is actually >>>> acting as a host for the exchange. >>> >>> Routers act as hosts for all routing protocol exchanges; that's not uni= que >>> to the router-server exchange. >>> >>>> There are more router IPsec implementations that can protect the >>>> control plane now, and meeting the requirements above would likely be >>>> doable. >>> >>> There are other potential reasons why IPsec may or may not be the best >>> choice, but I don't much care whether IPsec or TCP-AO is used; those ar= e the >>> appropriate choices if you care that the transport protocol is protecte= d. >>> >>> Joe >>> >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>> > From touch@isi.edu Thu Apr 21 22:27:55 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8FEFE0758 for ; Thu, 21 Apr 2011 22:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.335 X-Spam-Level: X-Spam-Status: No, score=-104.335 tagged_above=-999 required=5 tests=[AWL=0.868, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg52ou4rL-+5 for ; Thu, 21 Apr 2011 22:27:54 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfc.amsl.com (Postfix) with ESMTP id 7DA43E064E for ; Thu, 21 Apr 2011 22:27:54 -0700 (PDT) Received: from [192.168.1.94] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p3M5R67F014752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Apr 2011 22:27:17 -0700 (PDT) References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8H7) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8H7) From: Joe Touch Date: Thu, 21 Apr 2011 22:27:04 -0700 To: Christopher Morrow X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 05:27:56 -0000 On Apr 21, 2011, at 10:10 PM, Christopher Morrow w= rote: > On Fri, Apr 22, 2011 at 12:14 AM, Joe Touch wrote: >>=20 >>=20 >> On Apr 21, 2011, at 7:45 PM, Christopher Morrow = wrote: >>=20 >>> So.. round and round the rosemary bush we go, still we have no actual >>> things that run actual tcp-ao, so given that can we either: >>>=20 >>> 1) use md5 (as a MUST, with ssh as a MAY) and rev the doc at a later >>> point to say that AO is a MUST and remove md5 >>> 2) move this doc along the path >>> 3) get implementations of the protocol today to start using md5 >>=20 >> You could instead do what the TCP-AO rfc recommends for apps like BGP: >>=20 >> - MUST support TCP-AO >> - MAY also support TCP MD5 for backward compatibility >>=20 >> This avoids reinventing an answer for BGP caches and just applies the *cu= rrent* advice for BGP in general. >>=20 >=20 > bgp cache is not bgp... it's really just a random tcp session from a > router to a thing some where else. >=20 > (does that change your proposed above?) Nope. (and I was aware it isn't a BGP protocol connection) Joe >=20 > -Chris >=20 >> Joe >>=20 >>=20 >>>=20 >>> -chris >>> (co-chair-toe-socks-on) >>>=20 >>> On Wed, Apr 20, 2011 at 8:25 PM, Joe Touch wrote: >>>>=20 >>>>=20 >>>> On 4/20/2011 5:19 PM, Brian Weis wrote: >>>>>=20 >>>>> On Apr 20, 2011, at 1:40 PM, Joe Touch wrote: >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 4/11/2011 12:49 PM, Stephen Kent wrote: >>>>>>>=20 >>>>>>> At 9:30 PM -0700 4/6/11, Brian Weis wrote: >>>>>>>>=20 >>>>>>>> On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: >>>>>>>>=20 >>>>>>>>>> Getting a new application (such as the rtr protocol) >>>>>>>>>> specifying hmac-md5 mandatory to implement through a Secdir >>>>>>>>>> review and then the Security ADs just won't happen. The >>>>>>>>>> only exception I can think of is if there were no possible >>>>>>>>>> alternatives, and that's obviously not the case here. >>>>>>>>>=20 >>>>>>>>> with AO not implemented on any servers, routers not having >>>>>>>>> ssh libraries, and this being a server to router protocol, >>>>>>>>> what are the alternatives? >>>>>>>>>=20 >>>>>>>>> randy >>>>>>>>=20 >>>>>>>> I'm surprised IPsec hasn't been mentioned in this thread ... >>>>>>>> was it previously discussed and rejected? Correct me if I'm >>>>>>>> wrong, but I believe it's common for BGP routers to support >>>>>>>> IPsec and servers definitely support IPsec. On the router side, >>>>>>>> one or two IPsec sessions to servers should not be a burden. >>>>>>>> I'm less sure of the server IPsec scaling properties, but I >>>>>>>> would expect a LINUX or BSD kernel to have the scaling issues >>>>>>>> as were discussed earlier in this thread regarding SSH but I'm >>>>>>>> no expert here. >>>>>>>>=20 >>>>>>>> Brian >>>>>>>=20 >>>>>>> A few years ago we were told by vendors that many router >>>>>>> implementations of IPsec were available only to traffic passing >>>>>>> through a router, not to the control plane terminating in a >>>>>>> router. Unless that has changed, IPsec is not a good candidate >>>>>>> here. >>>>>>=20 >>>>>> FWIW, that was an artifact of the IPsec requirements for routers. >>>>>> 4301 has the following requirements: >>>>>>=20 >>>>>> (end sec 4.1, RFC 4301): In summary, >>>>>>=20 >>>>>> a) A host implementation of IPsec MUST support both transport and >>>>>> tunnel mode. This is true for native, BITS, and BITW >>>>>> implementations for hosts. >>>>>>=20 >>>>>> b) A security gateway MUST support tunnel mode and MAY support >>>>>> transport mode. If it supports transport mode, that should be used >>>>>> only when the security gateway is acting as a host, e.g., for >>>>>> network management, or to provide security between two intermediate >>>>>> systems along a path. >>>>>>=20 >>>>>> A gateway acts as a host for all its routing protocol connections, >>>>>> and thus its control plane should have to comply with (a). >>>>>>=20 >>>>>> I agree, that's why IPsec isn't a good choice to protect BGP, but >>>>>> we sort of created that situation in 4301, AFAICT. >>>>>>=20 >>>>>> Joe >>>>>=20 >>>>> I won't quibble with that argument as far as protecting BGP. But for >>>>> the "router-to-server" protocol described by this draft is actually >>>>> acting as a host for the exchange. >>>>=20 >>>> Routers act as hosts for all routing protocol exchanges; that's not uni= que >>>> to the router-server exchange. >>>>=20 >>>>> There are more router IPsec implementations that can protect the >>>>> control plane now, and meeting the requirements above would likely be >>>>> doable. >>>>=20 >>>> There are other potential reasons why IPsec may or may not be the best >>>> choice, but I don't much care whether IPsec or TCP-AO is used; those ar= e the >>>> appropriate choices if you care that the transport protocol is protecte= d. >>>>=20 >>>> Joe >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>>>=20 >>=20 From christopher.morrow@gmail.com Thu Apr 21 22:31:09 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7AFF6E07C3 for ; Thu, 21 Apr 2011 22:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MNswws1e8+2 for ; Thu, 21 Apr 2011 22:31:08 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 385D6E07AE for ; Thu, 21 Apr 2011 22:31:08 -0700 (PDT) Received: by wyb29 with SMTP id 29so284437wyb.31 for ; Thu, 21 Apr 2011 22:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tNUSnEh8rna7g957rO9RL/btaFNu+JzvRRZQwQpGsB8=; b=NEk+tKfQ6Ra6VbeZfUpdTTMR2/6ni49/jNOfvWqkHyBDNOhSOZovyukZ7e0eBWSTdy Lnd2ghgCVF6bILOcfGLAjGPnmg4IgX0q73wWWtgAIBxxG4bQsM1RUSOHUehDqF6E7+q5 tLhpJYqYLjA6wepdJvmQp/qZsXKf8duwwE0B4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ndPs8IJOWQgV/cyEOI6zME4leDuG95tnpANLpWVGQ2+393BzT1pXJhfzyFL6tMt+MN jhInWLLY8DMCdAUqbmdqdvAMSIfK5BrRsgjbrUHUdItAwyB0lWuK2UqWwPxSqLErkPVz uhLYZLSjTj4v2YdlbkvLe6DblGpZaEgx7VIUg= MIME-Version: 1.0 Received: by 10.216.24.73 with SMTP id w51mr676278wew.72.1303450266495; Thu, 21 Apr 2011 22:31:06 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.234.156 with HTTP; Thu, 21 Apr 2011 22:31:06 -0700 (PDT) In-Reply-To: References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> Date: Fri, 22 Apr 2011 01:31:06 -0400 X-Google-Sender-Auth: RLa1B2rYEr5ihTWkeq4XMMZ6bHk Message-ID: From: Christopher Morrow To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 05:31:09 -0000 On Fri, Apr 22, 2011 at 1:27 AM, Joe Touch wrote: > > > On Apr 21, 2011, at 10:10 PM, Christopher Morrow wrote: > >> On Fri, Apr 22, 2011 at 12:14 AM, Joe Touch wrote: >>> >>> >>> On Apr 21, 2011, at 7:45 PM, Christopher Morrow wrote: >>> >>>> So.. round and round the rosemary bush we go, still we have no actual >>>> things that run actual tcp-ao, so given that can we either: >>>> >>>> 1) use md5 (as a MUST, with ssh as a MAY) and rev the doc at a later >>>> point to say that AO is a MUST and remove md5 >>>> 2) move this doc along the path >>>> 3) get implementations of the protocol today to start using md5 >>> >>> You could instead do what the TCP-AO rfc recommends for apps like BGP: >>> >>> - MUST support TCP-AO >>> - MAY also support TCP MD5 for backward compatibility >>> >>> This avoids reinventing an answer for BGP caches and just applies the *= current* advice for BGP in general. >>> >> >> bgp cache is not bgp... it's really just a random tcp session from a >> router to a thing some where else. >> >> (does that change your proposed above?) > > Nope. (and I was aware it isn't a BGP protocol connection) awesome, was a tad worried your quote was specific to bgp... a loophole so to speak. >> >> -Chris >> >>> Joe >>> >>> >>>> >>>> -chris >>>> (co-chair-toe-socks-on) >>>> >>>> On Wed, Apr 20, 2011 at 8:25 PM, Joe Touch wrote: >>>>> >>>>> >>>>> On 4/20/2011 5:19 PM, Brian Weis wrote: >>>>>> >>>>>> On Apr 20, 2011, at 1:40 PM, Joe Touch wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/11/2011 12:49 PM, Stephen Kent wrote: >>>>>>>> >>>>>>>> At 9:30 PM -0700 4/6/11, Brian Weis wrote: >>>>>>>>> >>>>>>>>> On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: >>>>>>>>> >>>>>>>>>>> Getting a new application (such as the rtr protocol) >>>>>>>>>>> specifying hmac-md5 mandatory to implement through a Secdir >>>>>>>>>>> review and then the Security ADs just won't happen. The >>>>>>>>>>> only exception I can think of is if there were no possible >>>>>>>>>>> alternatives, and that's obviously not the case here. >>>>>>>>>> >>>>>>>>>> with AO not implemented on any servers, routers not having >>>>>>>>>> ssh libraries, and this being a server to router protocol, >>>>>>>>>> what are the alternatives? >>>>>>>>>> >>>>>>>>>> randy >>>>>>>>> >>>>>>>>> I'm surprised IPsec hasn't been mentioned in this thread ... >>>>>>>>> was it previously discussed and rejected? Correct me if I'm >>>>>>>>> wrong, but I believe it's common for BGP routers to support >>>>>>>>> IPsec and servers definitely support IPsec. On the router side, >>>>>>>>> one or two IPsec sessions to servers should not be a burden. >>>>>>>>> I'm less sure of the server IPsec scaling properties, but I >>>>>>>>> would expect a LINUX or BSD kernel to have the scaling issues >>>>>>>>> as were discussed earlier in this thread regarding SSH but I'm >>>>>>>>> no expert here. >>>>>>>>> >>>>>>>>> Brian >>>>>>>> >>>>>>>> A few years ago we were told by vendors that many router >>>>>>>> implementations of IPsec were available only to traffic passing >>>>>>>> through a router, not to the control plane terminating in a >>>>>>>> router. Unless that has changed, IPsec is not a good candidate >>>>>>>> here. >>>>>>> >>>>>>> FWIW, that was an artifact of the IPsec requirements for routers. >>>>>>> 4301 has the following requirements: >>>>>>> >>>>>>> (end sec 4.1, RFC 4301): In summary, >>>>>>> >>>>>>> a) A host implementation of IPsec MUST support both transport and >>>>>>> tunnel mode. =A0This is true for native, BITS, and BITW >>>>>>> implementations for hosts. >>>>>>> >>>>>>> b) A security gateway MUST support tunnel mode and MAY support >>>>>>> transport mode. =A0If it supports transport mode, that should be us= ed >>>>>>> only when the security gateway is acting as a host, e.g., for >>>>>>> network management, or to provide security between two intermediate >>>>>>> systems along a path. >>>>>>> >>>>>>> A gateway acts as a host for all its routing protocol connections, >>>>>>> and thus its control plane should have to comply with (a). >>>>>>> >>>>>>> I agree, that's why IPsec isn't a good choice to protect BGP, but >>>>>>> we sort of created that situation in 4301, AFAICT. >>>>>>> >>>>>>> Joe >>>>>> >>>>>> I won't quibble with that argument as far as protecting BGP. But for >>>>>> the "router-to-server" protocol described by this draft is actually >>>>>> acting as a host for the exchange. >>>>> >>>>> Routers act as hosts for all routing protocol exchanges; that's not u= nique >>>>> to the router-server exchange. >>>>> >>>>>> There are more router IPsec implementations that can protect the >>>>>> control plane now, and meeting the requirements above would likely b= e >>>>>> doable. >>>>> >>>>> There are other potential reasons why IPsec may or may not be the bes= t >>>>> choice, but I don't much care whether IPsec or TCP-AO is used; those = are the >>>>> appropriate choices if you care that the transport protocol is protec= ted. >>>>> >>>>> Joe >>>>> >>>>> >>>>> _______________________________________________ >>>>> sidr mailing list >>>>> sidr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sidr >>>>> >>> > From randy@psg.com Thu Apr 21 23:27:56 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 46026E06C5 for ; Thu, 21 Apr 2011 23:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqSW52zwqPQH for ; Thu, 21 Apr 2011 23:27:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id C7B3DE070B for ; Thu, 21 Apr 2011 23:27:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QD9qJ-000MiO-Lt; Fri, 22 Apr 2011 06:27:51 +0000 Date: Fri, 22 Apr 2011 15:28:26 +0900 Message-ID: From: Randy Bush To: Joe Touch In-Reply-To: <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> References: <289DB32D-D175-49DE-AA82-100407F64C23@juniper.net> <20110401210506.GA3082@juniper.net> <20110404083237.GA1860@juniper.net> <20110404125015.GA3277@juniper.net> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 06:27:56 -0000 > - MUST support TCP-AO send code From christopher.morrow@gmail.com Sat Apr 23 22:17:38 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 15DD3E06CF for ; Sat, 23 Apr 2011 22:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.979 X-Spam-Level: X-Spam-Status: No, score=-102.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3LkvPfPk7CS for ; Sat, 23 Apr 2011 22:17:37 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 19E82E06A0 for ; Sat, 23 Apr 2011 22:17:36 -0700 (PDT) Received: by wyb29 with SMTP id 29so1221785wyb.31 for ; Sat, 23 Apr 2011 22:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1iOb1PODtYswqOAUcq7iPRffGcLmBN/CjNql9EoN7K8=; b=NNiG53DJmZ6U/CjzJ+ErimUrwtHk1qb0ey/PBf5SBPLaHDhfTDpnmnaRhCgZCcQcdE aYlD+u1icB8JvJmFqpwOHqYRqVRQHKA4tICbvMDVxvfu7gQOKzLR8iwLfAw4E64klCoV I/RT1kBEroOn0XDiQc5iOamYGboD0vm46qL9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=sUDeas2B+mML0QXa8ULGzzHXAZpPjYxtDhpPP52KxWMYZBVyHtpJJAO9/86dbvzZbr UqncFC3+EdriptrnywSWg3GbM8Aard/UPM+gtdJM2nO6DG6mB+an78wHPOBIVe48S7PQ xu6Kr692m/xDG53jhp2qepoBd9qNk7ZApUNLg= MIME-Version: 1.0 Received: by 10.216.245.4 with SMTP id n4mr2521393wer.88.1303622254698; Sat, 23 Apr 2011 22:17:34 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.234.156 with HTTP; Sat, 23 Apr 2011 22:17:34 -0700 (PDT) In-Reply-To: <4DAF421A.9060100@isi.edu> References: <4DAF421A.9060100@isi.edu> Date: Sun, 24 Apr 2011 01:17:34 -0400 X-Google-Sender-Auth: qCZdFOI_N1189djzZxmoYq7NCyI Message-ID: From: Christopher Morrow To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 05:17:38 -0000 first, thanks! :) On Wed, Apr 20, 2011 at 4:29 PM, Joe Touch wrote: > Hi, all, > > I've reviewed the discussion about mandatory-to-implement connection > security that dates back to Morrow's post of 1 Apr: > http://www.ietf.org/mail-archive/web/sidr/current/msg02623.html > > I'd like to note a few things: > > 1) ssh does not protect the transport connection > ssh is an application protocol, not a transport protocol > > It provides privacy and authentication at the application layer, of the data > over the TCP connection, but that connection can be interrupted by an > attacker. This may not have the same impact as for vanilla BGP (where the > connection disappearing causes routes to be removed), but should be a > consideration in a "mandatory to implement" component, IMO. > > 2) TCP-AO was designed for BGP > TCP-AO was designed to get around concerns with the use of IPsec for BGP > protection, and to correct for weaknesses in TCP MD5. > > Any platform that is intended to use BGP in a protected way will need to > implement TCP-AO anyway. Using that mechanism to protect other parts of BGP > seems appropriate. > > 3) TCP-AO obsoletes TCP MD5 > We did not deprecate TCP MD5 for legacy reasons only. It should not be > recommended in any new cases. > > 4) a SIDR solution assuming TCP-AO isn't available on servers is an interim > only > > RFCs ought not focus on short term solutions, especially ones that are so > easily corrected. > > If the issue is the lack of a TCP-AO implementation in Linux and FreeBSD, it > would be more productive to find the resources (6 man-months approx.) to > just write this than even to discuss it on this list at length further. I don't think we've got folks yet volunteering to do this... though it'd be nice :) > If you do insist on including other alternatives, I would strongly suggest > listing only IPsec; if you do include ssh (or, AFAICT, if you really want to > get to servers, why not tls? surely servers are as likely if not more so to > have HTTPS support) then you should note the lack of protection to the > transport layer, and any implications that result. it's not clear to me that https client support exists in routers, there are also some issues with cert validation to think about (I think, though maybe that's a simple problem where the cert only validates up a chain for your as-level-cert? no other CA's accepted...). In any case, this should provide some thoughts to crunch on as well... Can we spiral into an answer soon folks? -Chris > > Joe > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Sat Apr 23 22:47:09 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5C8DAE073C for ; Sat, 23 Apr 2011 22:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1lGdkK6nsOn for ; Sat, 23 Apr 2011 22:47:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id B8F0EE06A0 for ; Sat, 23 Apr 2011 22:47:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QDs9y-0006we-RR; Sun, 24 Apr 2011 05:47:07 +0000 Date: Sun, 24 Apr 2011 14:47:47 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <4DAF421A.9060100@isi.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 05:47:09 -0000 > there are also some issues with cert validation to think about (I > think, though maybe that's a simple problem where the cert only > validates up a chain for your as-level-cert? no other CA's > accepted...). wrong trust relationship. e.g. i don't think you want the upstream to issue a router cert to a downstream who wants to use upstream's server. the way i figure it is that the docco can stay as it is regarding transport, and we can use cleartext or ssh while running a betting pool on which is slower, AO code in routers and servers or endless ietf discussions. we have running code, no other doc depends on this one, so ietf process can remain a source of amusement. a couple of changes are actually in a yet-to-be-published rev o 5.5 the router is no longer expected to keep a ref count The cache server is responsible for assuring that it has told the router client to have one and only one IPvX PDU for a unique {prefix, len, max-len, asn} at any one point in time. Should the router client receive an IPvX PDU with a {prefix, len, max-len, asn} identical to one it already has active, it SHOULD raise a Duplicate Announcement Received error. o Brian Weis's comment on BGPsec also has some relevance here. so i added a bit to sec 4 As a cache server must evaluate certificates and ROAs which are time dependent, servers' clocks MUST be correct to a tolerance of approximately an hour. or maybe there is some nice text elsewhere which covers this? randy From ietfc@btconnect.com Mon Apr 25 02:49:06 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0EF6EE06A0 for ; Mon, 25 Apr 2011 02:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo3eaGRfPZcX for ; Mon, 25 Apr 2011 02:49:04 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfc.amsl.com (Postfix) with ESMTP id 78CB3E0693 for ; Mon, 25 Apr 2011 02:49:04 -0700 (PDT) Received: from host86-134-204-170.range86-134.btcentralplus.com (HELO pc6) ([86.134.204.170]) by c2bthomr13.btconnect.com with SMTP id CPM49444; Mon, 25 Apr 2011 10:48:41 +0100 (BST) Message-ID: <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Joe Touch" , "Christopher Morrow" References: <4DAF44AC.8060408@isi.edu><4DAF796C.7010807@isi.edu><409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> Date: Mon, 25 Apr 2011 10:47:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4DB54379.0026, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.4DB54382.008E,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 09:49:06 -0000 ----- Original Message ----- From: "Joe Touch" To: "Christopher Morrow" Cc: "sidr wg list" Sent: Friday, April 22, 2011 7:27 AM > On Apr 21, 2011, at 10:10 PM, Christopher Morrow wrote: > On Fri, Apr 22, 2011 at 12:14 AM, Joe Touch wrote: > >> > >> On Apr 21, 2011, at 7:45 PM, Christopher Morrow wrote: > >> > >>> So.. round and round the rosemary bush we go, still we have no actual > >>> things that run actual tcp-ao, so given that can we either: > >>> > >>> 1) use md5 (as a MUST, with ssh as a MAY) and rev the doc at a later > >>> point to say that AO is a MUST and remove md5 > >>> 2) move this doc along the path > >>> 3) get implementations of the protocol today to start using md5 > >> > >> You could instead do what the TCP-AO rfc recommends for apps like BGP: > >> > >> - MUST support TCP-AO > >> - MAY also support TCP MD5 for backward compatibility > >> > >> This avoids reinventing an answer for BGP caches and just applies the *current* advice for BGP in general. > > > > bgp cache is not bgp... it's really just a random tcp session from a > > router to a thing some where else. > > > > (does that change your proposed above?) > > Nope. (and I was aware it isn't a BGP protocol connection) Joe I think that the point is not that it is or is not a BGP connection but that security for BGP was predicated on the assumption that the TCP connection would be short in terms of hops, ie none, and it was that that made a less stringent approach to security acceptable, one that would not be acceptable for an Internet wide access for - say - a Web site. What I am missing is not whether or not this is BGP, but whether or not the connection will have the properties of BGP, of being very short. My suspicion is that the data will be coming from all over the place, Internet-wide (as with CRL) and so the security should be Web-like and not BGP-like; ie TCP-AO will not do. Tom Petch > > Joe > > > > > > -Chris > > > >> Joe > >> > >> > >>> > >>> -chris > >>> (co-chair-toe-socks-on) > >>> > >>> On Wed, Apr 20, 2011 at 8:25 PM, Joe Touch wrote: > >>>> > >>>> > >>>> On 4/20/2011 5:19 PM, Brian Weis wrote: > >>>>> > >>>>> On Apr 20, 2011, at 1:40 PM, Joe Touch wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On 4/11/2011 12:49 PM, Stephen Kent wrote: > >>>>>>> > >>>>>>> At 9:30 PM -0700 4/6/11, Brian Weis wrote: > >>>>>>>> > >>>>>>>> On Apr 6, 2011, at 5:46 PM, Randy Bush wrote: > >>>>>>>> > >>>>>>>>>> Getting a new application (such as the rtr protocol) > >>>>>>>>>> specifying hmac-md5 mandatory to implement through a Secdir > >>>>>>>>>> review and then the Security ADs just won't happen. The > >>>>>>>>>> only exception I can think of is if there were no possible > >>>>>>>>>> alternatives, and that's obviously not the case here. > >>>>>>>>> > >>>>>>>>> with AO not implemented on any servers, routers not having > >>>>>>>>> ssh libraries, and this being a server to router protocol, > >>>>>>>>> what are the alternatives? > >>>>>>>>> > >>>>>>>>> randy > >>>>>>>> > >>>>>>>> I'm surprised IPsec hasn't been mentioned in this thread ... > >>>>>>>> was it previously discussed and rejected? Correct me if I'm > >>>>>>>> wrong, but I believe it's common for BGP routers to support > >>>>>>>> IPsec and servers definitely support IPsec. On the router side, > >>>>>>>> one or two IPsec sessions to servers should not be a burden. > >>>>>>>> I'm less sure of the server IPsec scaling properties, but I > >>>>>>>> would expect a LINUX or BSD kernel to have the scaling issues > >>>>>>>> as were discussed earlier in this thread regarding SSH but I'm > >>>>>>>> no expert here. > >>>>>>>> > >>>>>>>> Brian > >>>>>>> > >>>>>>> A few years ago we were told by vendors that many router > >>>>>>> implementations of IPsec were available only to traffic passing > >>>>>>> through a router, not to the control plane terminating in a > >>>>>>> router. Unless that has changed, IPsec is not a good candidate > >>>>>>> here. > >>>>>> > >>>>>> FWIW, that was an artifact of the IPsec requirements for routers. > >>>>>> 4301 has the following requirements: > >>>>>> > >>>>>> (end sec 4.1, RFC 4301): In summary, > >>>>>> > >>>>>> a) A host implementation of IPsec MUST support both transport and > >>>>>> tunnel mode. This is true for native, BITS, and BITW > >>>>>> implementations for hosts. > >>>>>> > >>>>>> b) A security gateway MUST support tunnel mode and MAY support > >>>>>> transport mode. If it supports transport mode, that should be used > >>>>>> only when the security gateway is acting as a host, e.g., for > >>>>>> network management, or to provide security between two intermediate > >>>>>> systems along a path. > >>>>>> > >>>>>> A gateway acts as a host for all its routing protocol connections, > >>>>>> and thus its control plane should have to comply with (a). > >>>>>> > >>>>>> I agree, that's why IPsec isn't a good choice to protect BGP, but > >>>>>> we sort of created that situation in 4301, AFAICT. > >>>>>> > >>>>>> Joe > >>>>> > >>>>> I won't quibble with that argument as far as protecting BGP. But for > >>>>> the "router-to-server" protocol described by this draft is actually > >>>>> acting as a host for the exchange. > >>>> > >>>> Routers act as hosts for all routing protocol exchanges; that's not unique > >>>> to the router-server exchange. > >>>> > >>>>> There are more router IPsec implementations that can protect the > >>>>> control plane now, and meeting the requirements above would likely be > >>>>> doable. > >>>> > >>>> There are other potential reasons why IPsec may or may not be the best > >>>> choice, but I don't much care whether IPsec or TCP-AO is used; those are the > >>>> appropriate choices if you care that the transport protocol is protected. > >>>> > >>>> Joe > >>>> > >>>> > >>>> _______________________________________________ > >>>> sidr mailing list > >>>> sidr@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sidr > >>>> > >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Mon Apr 25 03:10:56 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ECCA9E071F for ; Mon, 25 Apr 2011 03:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HApt5b46vhD2 for ; Mon, 25 Apr 2011 03:10:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfc.amsl.com (Postfix) with ESMTP id F1F63E0693 for ; Mon, 25 Apr 2011 03:10:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QEIko-000Cxe-1C; Mon, 25 Apr 2011 10:10:54 +0000 Date: Mon, 25 Apr 2011 19:11:37 +0900 Message-ID: From: Randy Bush To: Tom Petch In-Reply-To: <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> References: <4DAF44AC.8060408@isi.edu> <4DAF796C.7010807@isi.edu> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 10:10:57 -0000 > What I am missing is not whether or not this is BGP, but > whether or not the connection will have the properties of > BGP, of being very short. My suspicion is that the > data will be coming from all over the place, Internet-wide > (as with CRL) and so the security should be Web-like and not > BGP-like; ie TCP-AO will not do. perhaps long-hop will be a rare case, and you will want your routers to have nearby caches. see draft-ymbk-rpki-origin-ops. remember, the caches talk to each other using object, not transport, security. it's just the final hop to the router that we're talking about here. randy From touch@isi.edu Mon Apr 25 08:27:15 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 54B84E06C1 for ; Mon, 25 Apr 2011 08:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GWUWnqJ7gLm for ; Mon, 25 Apr 2011 08:27:14 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfc.amsl.com (Postfix) with ESMTP id 6987AE0682 for ; Mon, 25 Apr 2011 08:27:14 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p3PFQfwR009056 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 25 Apr 2011 08:26:44 -0700 (PDT) Message-ID: <4DB592B3.3090805@isi.edu> Date: Mon, 25 Apr 2011 08:26:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "t.petch" References: <4DAF44AC.8060408@isi.edu><4DAF796C.7010807@isi.edu><409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> In-Reply-To: <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p3PFQfwR009056 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 15:27:15 -0000 Hi, Tom, On 4/25/2011 1:47 AM, t.petch wrote: .... > I think that the point is not that it is or is not a BGP connection > but that security for BGP was predicated on the assumption that > the TCP connection would be short in terms of hops, ie none, > and it was that that made a less stringent approach to security > acceptable, one that would not be acceptable for an Internet > wide access for - say - a Web site. Hopcount security, i.e., GTSM (RFC 3682) is not at all related to TCP-AO. TCP-AO provides replay protection, includes extended sequence numbers to account for seqno rollover, and support for changing keys during a connection without impact to TCP. It also uses per-connection keys derived from master keys. > What I am missing is not whether or not this is BGP, but > whether or not the connection will have the properties of > BGP, of being very short. My suspicion is that the > data will be coming from all over the place, Internet-wide > (as with CRL) and so the security should be Web-like and not > BGP-like; ie TCP-AO will not do. I encourage you to take another look at TCP-AO; there is nothing therein that is focused exclusively on any property of BGP. It was intended as a generic mechanism to support transport authentication for TCP connections. Joe From oliver.borchert@nist.gov Mon Apr 25 08:30:06 2011 Return-Path: X-Original-To: sidr@ietfc.amsl.com Delivered-To: sidr@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 12B84E0682 for ; Mon, 25 Apr 2011 08:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypeXBGE1bHzV for ; Mon, 25 Apr 2011 08:30:05 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by ietfc.amsl.com (Postfix) with ESMTP id 75D4BE0664 for ; Mon, 25 Apr 2011 08:30:05 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p3PFTv2L009813; Mon, 25 Apr 2011 11:29:57 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 25 Apr 2011 11:29:57 -0400 From: "Borchert, Oliver" To: Randy Bush Date: Mon, 25 Apr 2011 11:29:56 -0400 Thread-Topic: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?) Thread-Index: AcwCQwbtMZgVb0vFT5edlKlgFl6+1ABGRlcg Message-ID: References: <4DAF421A.9060100@isi.edu> 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" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: oliver.borchert@nist.gov Cc: sidr wg list Subject: Re: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 15:30:06 -0000 > > a couple of changes are actually in a yet-to-be-published rev > > o 5.5 the router is no longer expected to keep a ref count > > The cache server is responsible for assuring that it has told the > router client to have one and only one IPvX PDU for a unique > {prefix, len, max-len, asn} at any one point in time. Should the > router client receive an IPvX PDU with a {prefix, len, max-len, > asn} identical to one it already has active, it SHOULD raise a > Duplicate Announcement Received error. > Randy, Do I understand you correctly that you move away from your position that the prefix cache sends a 1:1 image to the server as you mentioned in an earlier post? Therefore with the given ROAs (below): ROA1(p1 maxlen m1 valid from t0-t5) and ROA2(p1 maxlen m1 valid from t3-t9) Can I expect the following behavior? The router will receive only one Whitelist announcement for (p1 m1) at or shortly after t0 followed by one Whitelist withdrawal for (p1 m1) at or shortly after t9? Also the router will not see anything that indicates a change in ROAs (ROA1 - ROA2) where the content is the same. Therefore from the routers point of view only one ROA was existent during the time from t0-t9. When do you plan to publish this change? Oliver ---------------------------------------------------------------------------- Oliver Borchert - Computer Scientist National Institute of Standards and Technology United States Department of Commerce phone: 301-975-4856, fax: 301-975-6238 From oliver.borchert@nist.gov Mon Apr 25 15:08:55 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14258E064A for ; Mon, 25 Apr 2011 15:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwR-KHEE9sa1 for ; Mon, 25 Apr 2011 15:08:53 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCF5E062A for ; Mon, 25 Apr 2011 15:08:49 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p3PM8ejh007249; Mon, 25 Apr 2011 18:08:40 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 25 Apr 2011 18:08:40 -0400 From: "Borchert, Oliver" To: Randy Bush Date: Mon, 25 Apr 2011 18:08:40 -0400 Thread-Topic: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?) Thread-Index: AcwDk9Fs4f+mzXwGSse+ZaR+J/V2EgAAR8OA Message-ID: References: <4DAF421A.9060100@isi.edu> 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" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: oliver.borchert@nist.gov Cc: sidr wg list Subject: Re: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 22:08:55 -0000 > > > Do I understand you correctly that you move away from your position > > that the prefix cache sends a 1:1 image to the server as you mentioned > > in an earlier post? > > s/move away/was shoved/ :) > This simplifies the implementation on the routers side. I like that ;-) > > Therefore with the given ROAs (below): > > ROA1(p1 maxlen m1 valid from t0-t5) and > > ROA2(p1 maxlen m1 valid from t3-t9) > > > > Can I expect the following behavior? > > > > The router will receive only one Whitelist announcement for (p1 m1) at > > or shortly after t0 followed by one Whitelist withdrawal for (p1 m1) > > at or shortly after t9? > > > > Also the router will not see anything that indicates a change in ROAs > > (ROA1 - ROA2) where the content is the same. Therefore from the > > routers point of view only one ROA was existent during the time from > > t0-t9. > > yes, presuming t0 <= t3 <= t5 <= t9 Yes > and presuming the as-num is the same in both Yes > and presuming the prefix length is the same in both and yes > > > When do you plan to publish this change? > > i could do it any time. i guess i should. lemme finish some big makes > first Sounds great > > randy Oliver From randy@psg.com Mon Apr 25 15:13:11 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9873E0678 for ; Mon, 25 Apr 2011 15:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.537 X-Spam-Level: X-Spam-Status: No, score=-4.537 tagged_above=-999 required=5 tests=[AWL=2.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGdYVrlnRIZV for ; Mon, 25 Apr 2011 15:13:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE94E066F for ; Mon, 25 Apr 2011 15:13:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QETnA-000F11-GM; Mon, 25 Apr 2011 21:58:04 +0000 Date: Tue, 26 Apr 2011 06:58:49 +0900 Message-ID: From: Randy Bush To: "Borchert, Oliver" In-Reply-To: References: <4DAF421A.9060100@isi.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 22:13:12 -0000 > Do I understand you correctly that you move away from your position > that the prefix cache sends a 1:1 image to the server as you mentioned > in an earlier post? s/move away/was shoved/ :) > Therefore with the given ROAs (below): > ROA1(p1 maxlen m1 valid from t0-t5) and > ROA2(p1 maxlen m1 valid from t3-t9) > > Can I expect the following behavior? > > The router will receive only one Whitelist announcement for (p1 m1) at > or shortly after t0 followed by one Whitelist withdrawal for (p1 m1) > at or shortly after t9? > > Also the router will not see anything that indicates a change in ROAs > (ROA1 - ROA2) where the content is the same. Therefore from the > routers point of view only one ROA was existent during the time from > t0-t9. yes, presuming t0 <= t3 <= t5 <= t9 and presuming the as-num is the same in both and presuming the prefix length is the same in both > When do you plan to publish this change? i could do it any time. i guess i should. lemme finish some big makes first randy From randy@psg.com Mon Apr 25 15:13:24 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E35BE0678 for ; Mon, 25 Apr 2011 15:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.614 X-Spam-Level: X-Spam-Status: No, score=-4.614 tagged_above=-999 required=5 tests=[AWL=1.985, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TE0zQcPT1lTw for ; Mon, 25 Apr 2011 15:13:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id C1B03E066F for ; Mon, 25 Apr 2011 15:13:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QEU0m-000F41-66; Mon, 25 Apr 2011 22:12:08 +0000 Date: Tue, 26 Apr 2011 07:12:53 +0900 Message-ID: From: Randy Bush To: "Borchert, Oliver" In-Reply-To: References: <4DAF421A.9060100@isi.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 22:13:24 -0000 >>> Do I understand you correctly that you move away from your position >>> that the prefix cache sends a 1:1 image to the server as you >>> mentioned in an earlier post? >> s/move away/was shoved/ :) > This simplifies the implementation on the routers side. and you can guess who shoved. though, actually, i got it from both sides, routers and server. running code is a strong incentive. randy From touch@isi.edu Mon Apr 25 15:37:12 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1CCE06A0 for ; Mon, 25 Apr 2011 15:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.58 X-Spam-Level: X-Spam-Status: No, score=-104.58 tagged_above=-999 required=5 tests=[AWL=2.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfbmbVXmj8oX for ; Mon, 25 Apr 2011 15:37:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D8C78E069E for ; Mon, 25 Apr 2011 15:37:11 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p3PMaTv1026694 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 25 Apr 2011 15:36:30 -0700 (PDT) Message-ID: <4DB5F76D.7060104@isi.edu> Date: Mon, 25 Apr 2011 15:36:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Christopher Morrow References: <4DAF421A.9060100@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: sidr@ietf.org Subject: Re: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 22:37:12 -0000 Hi, all, On 4/23/2011 10:17 PM, Christopher Morrow wrote: ... >> If the issue is the lack of a TCP-AO implementation in Linux and FreeBSD, it >> would be more productive to find the resources (6 man-months approx.) to >> just write this than even to discuss it on this list at length further. > > I don't think we've got folks yet volunteering to do this... though > it'd be nice :) FWIW, I'm working on arranging this now. >> If you do insist on including other alternatives, I would strongly suggest >> listing only IPsec; if you do include ssh (or, AFAICT, if you really want to >> get to servers, why not tls? surely servers are as likely if not more so to >> have HTTPS support) then you should note the lack of protection to the >> transport layer, and any implications that result. > > it's not clear to me that https client support exists in routers, > there are also some issues with cert validation to think about (I > think, though maybe that's a simple problem where the cert only > validates up a chain for your as-level-cert? no other CA's > accepted...). This brings up a useful question - what is the security model? CAs, self-signed certs, or just preshared keys? The latter is very easy to support in TCP MD5 and will be similarly simple in TCP-AO, but doesn't seem to be the common mode for SSH (you'd need preshared keys without passwords, and that's not as commonly used, AFAICT). Joe From Internet-Drafts@ietf.org Mon Apr 25 16:00:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40FDE067D; Mon, 25 Apr 2011 16:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KH5PyM8vT90D; Mon, 25 Apr 2011 16:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3962EE0689; Mon, 25 Apr 2011 16:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110425230002.1805.29617.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2011 16:00:02 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 23:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The RPKI/Router Protocol Author(s) : R. Bush, R. Austein Filename : draft-ietf-sidr-rpki-rtr-12.txt Pages : 22 Date : 2011-04-25 In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers over ssh. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-rtr-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-25154512.I-D@ietf.org> --NextPart-- From randy@psg.com Mon Apr 25 19:55:38 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF860E06B7 for ; Mon, 25 Apr 2011 19:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.685 X-Spam-Level: X-Spam-Status: No, score=-4.685 tagged_above=-999 required=5 tests=[AWL=1.914, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sh7tqw+vc0zm for ; Mon, 25 Apr 2011 19:55:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id D38F9E069E for ; Mon, 25 Apr 2011 19:55:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QEYPu-000HSU-1B; Tue, 26 Apr 2011 02:54:22 +0000 Date: Tue, 26 Apr 2011 11:55:07 +0900 Message-ID: From: Randy Bush To: Brian Weis User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 02:55:39 -0000 how about the following in draft-ymbk-bgpsec-ops? As a router must evaluate certificates and ROAs which are time dependent, routers' clocks MUST be correct to a tolerance of approximately an hour. If a router believes it has bogus clock, e.g. if it is 1970, 2005, or similar, it SHOULD NOT attempt to validate incoming updates. Severs SHOULD provide time service, such as NTP [RFC5905], to client routers. randy From rbarnes@bbn.com Mon Apr 25 20:13:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD31DE06CA for ; Mon, 25 Apr 2011 20:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOmOEEgB4Rnt for ; Mon, 25 Apr 2011 20:13:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D9844E06C3 for ; Mon, 25 Apr 2011 20:13:07 -0700 (PDT) Received: from [128.89.253.196] (port=61805 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QEYi1-000BY8-Ps; Mon, 25 Apr 2011 23:13:05 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 25 Apr 2011 23:13:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <99F65631-6388-471D-952A-BB67088AF96D@bbn.com> References: To: Randy Bush X-Mailer: Apple Mail (2.1082) Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 03:13:08 -0000 It's not clear to me what "1970, 2005, or similar" means? Numbers with = four digits? Five syllables*? Maybe it would be clearer to use some heuristic based on the set of = dates on certs/ROAs? Based on the assumption that the ROA issuers of = the world will be reasonably well in sync with real time.=20 If you're more than a few years off from the latest ROA issuance dates, = then you're probably bogus. Say, take the average issuance of the most = recent 100 ROAs and see if you're more than 5 years off. * "Two thousand *and* five" On Apr 25, 2011, at 10:55 PM, Randy Bush wrote: > how about the following in draft-ymbk-bgpsec-ops? >=20 > As a router must evaluate certificates and ROAs which are time > dependent, routers' clocks MUST be correct to a tolerance of > approximately an hour. >=20 > If a router believes it has bogus clock, e.g. if it is 1970, 2005, = or > similar, it SHOULD NOT attempt to validate incoming updates. >=20 > Severs SHOULD provide time service, such as NTP [RFC5905], to client > routers. >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Mon Apr 25 20:16:12 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7990AE06C3 for ; Mon, 25 Apr 2011 20:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.751 X-Spam-Level: X-Spam-Status: No, score=-4.751 tagged_above=-999 required=5 tests=[AWL=1.848, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZlJMER2G+um for ; Mon, 25 Apr 2011 20:16:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id C60B7E06B7 for ; Mon, 25 Apr 2011 20:16:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QEYl1-000HW3-69; Tue, 26 Apr 2011 03:16:11 +0000 Date: Tue, 26 Apr 2011 12:16:56 +0900 Message-ID: From: Randy Bush To: "Richard L. Barnes" In-Reply-To: <99F65631-6388-471D-952A-BB67088AF96D@bbn.com> References: <99F65631-6388-471D-952A-BB67088AF96D@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 03:16:12 -0000 > It's not clear to me what "1970, 2005, or similar" means? you do not write router code. those are the most common "clock is not set" years. even unix hackers know the first. > If you're more than a few years off from the latest ROA issuance > dates, then you're probably bogus. Say, take the average issuance of > the most recent 100 ROAs and see if you're more than 5 years off. a good example of how complexity opens attack vectors randy From terry.manderson@icann.org Mon Apr 25 20:31:20 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43D2E06D4 for ; Mon, 25 Apr 2011 20:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xr2g-W35qSvo for ; Mon, 25 Apr 2011 20:31:20 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 358F2E06D3 for ; Mon, 25 Apr 2011 20:31:20 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 25 Apr 2011 20:31:19 -0700 From: Terry Manderson To: Randy Bush , Brian Weis Date: Mon, 25 Apr 2011 20:31:18 -0700 Thread-Topic: [sidr] time Thread-Index: AcwDvX4ClBB2HXInSZSCtRsfZaErrQABOljR Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 03:31:20 -0000 On 26/04/11 12:55 PM, "Randy Bush" wrote: > how about the following in draft-ymbk-bgpsec-ops? >=20 > As a router must evaluate certificates and ROAs which are time > dependent, routers' clocks MUST be correct to a tolerance of > approximately an hour. So what you are allowing here is a clock signing/validation drift of +/- 60 minutes. yeah? >=20 > If a router believes it has bogus clock, e.g. if it is 1970, 2005, or > similar, it SHOULD NOT attempt to validate incoming updates. My guess here is you mean that the clock hasn't been set, based on your example. Might be best just to say that if a clock isn't stratum 1 or 2 (or something) NTP sourced than validation should be postponed. Otherwise I find it difficult to consume how a router itself will know if it's clock has a drift of over an hour. especially if its NTP source is wrong. >=20 > Severs SHOULD provide time service, such as NTP [RFC5905], to client > routers. >=20 Does this need to be said if you are making a MUST statement for NTP? Terry From randy@psg.com Mon Apr 25 22:30:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F79E06E7 for ; Mon, 25 Apr 2011 22:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.812 X-Spam-Level: X-Spam-Status: No, score=-4.812 tagged_above=-999 required=5 tests=[AWL=1.787, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h712dPxHXTG1 for ; Mon, 25 Apr 2011 22:30:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 7003DE06CD for ; Mon, 25 Apr 2011 22:30:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QEaq4-000HrD-L1; Tue, 26 Apr 2011 05:29:32 +0000 Date: Tue, 26 Apr 2011 14:30:18 +0900 Message-ID: From: Randy Bush To: Terry Manderson In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:30:54 -0000 >> As a router must evaluate certificates and ROAs which are time >> dependent, routers' clocks MUST be correct to a tolerance of >> approximately an hour. > So what you are allowing here is a clock signing/validation drift of > +/- 60 minutes. yeah? good guess :) >> If a router believes it has bogus clock, e.g. if it is 1970, 2005, >> or similar, it SHOULD NOT attempt to validate incoming updates. > My guess here is you mean that the clock hasn't been set, based on > your example. Might be best just to say that if a clock isn't stratum > 1 or 2 (or something) NTP sourced than validation should be postponed. few routers are strat 1 or 2, and i do not think it wise to go to such level of detail. to stay within one hour, strat 42 would probably be fine. > Otherwise I find it difficult to consume how a router itself will know > if it's clock has a drift of over an hour. i suggested two well-known ways to detect an unitialized clock > especially if its NTP source is wrong. perhaps the router should read the common advice to ntp clients? like not relying on a single source, etc. >> Severs SHOULD provide time service, such as NTP [RFC5905], to client >> routers. > Does this need to be said if you are making a MUST statement for NTP? first, i made no such statement. second, this statement is about servers, not about routers. third, i obviously thought it a good idea for servers to offer this service in addition to rpki data. but it is intentionally a should not a must. so, i have hacked As a router must evaluate certificates and ROAs which are time dependent, routers' clocks MUST be correct to a tolerance of approximately an hour. If a router has reason to believe its clock is seriouly incorrect, it SHOULD NOT attempt to validate incoming updates. It SHOULD defer validation until it believes it is within reasonable time tolerance. Servers SHOULD provide time service, such as NTP [RFC5905], to client routers. randy From randy@psg.com Mon Apr 25 22:36:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48889E0700 for ; Mon, 25 Apr 2011 22:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.87 X-Spam-Level: X-Spam-Status: No, score=-4.87 tagged_above=-999 required=5 tests=[AWL=1.729, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSLozNEg0eTp for ; Mon, 25 Apr 2011 22:36:50 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id C2EEAE06F5 for ; Mon, 25 Apr 2011 22:36:50 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QEax8-000HsR-A2; Tue, 26 Apr 2011 05:36:50 +0000 Date: Tue, 26 Apr 2011 14:37:36 +0900 Message-ID: From: Randy Bush To: Terry Manderson In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:36:51 -0000 >>> As a router must evaluate certificates and ROAs which are time >>> dependent, routers' clocks MUST be correct to a tolerance of >>> approximately an hour. >> So what you are allowing here is a clock signing/validation drift of >> +/- 60 minutes. yeah? > good guess :) actually, rereading and feeling pedantic, +- 120 min. i.e. the sending router could be slow 60 minutes and the receiving router fast 60 minutes. randy From christopher.morrow@gmail.com Mon Apr 25 22:40:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06056E06FA for ; Mon, 25 Apr 2011 22:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUvith4rqF10 for ; Mon, 25 Apr 2011 22:40:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 38136E06F5 for ; Mon, 25 Apr 2011 22:40:12 -0700 (PDT) Received: by wyb29 with SMTP id 29so205605wyb.31 for ; Mon, 25 Apr 2011 22:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l1GXWEztOL1yqATyIr7DVZuPGze2a/Ruq4IJKq2HdUM=; b=junSOXoQ8mrYajQwgPhPcQaj00mZXRheQ35WaLptuLmdKTA5goz3barPRsL9EfsbnP L/asyWc8y1qorzYYum1DA6At004Ri+WpEtwis9jrlTwu2NNwGdiHGf8a8YymNf0Ss5AO 7sOL3IoRwZXVejdSVuI8JvqriEkWKwl81md2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IkG99IdZjGzur7h6ywyHoEL7lfMRMIVKYoZF0tQ6Gd3oAPGyu2kkgs3sbwT2MeAT5s UstuE+6fwZ/S+MfBU8RPIXhEkA8nc9nHY3TUfmPENc+LZx5dXI9uzxGmmLZf5OiWcQHk unhNgWk4ja6kH94iyXC2a10oeAkJUjaN5bbZM= MIME-Version: 1.0 Received: by 10.216.9.141 with SMTP id 13mr4122747wet.73.1303796411240; Mon, 25 Apr 2011 22:40:11 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.234.156 with HTTP; Mon, 25 Apr 2011 22:40:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Apr 2011 01:40:11 -0400 X-Google-Sender-Auth: MXPbDFOHfhGIcPLeWCJjtHzwJxk Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:40:13 -0000 (hate to jump into the fray, but...) On Tue, Apr 26, 2011 at 1:30 AM, Randy Bush wrote: > so, i have hacked > > =A0 As a router must evaluate certificates and ROAs which are time > =A0 dependent, routers' clocks MUST be correct to a tolerance of > =A0 approximately an hour. > does there need to be a 'why' for the 'approximately an hour'? (like: "since granularity of cert time-to-live's is 30 mins on the minimum side" ... wordsmith or whatever as appropriate) > =A0 If a router has reason to believe its clock is seriouly incorrect, it 'has reason to believe' ... seems hard to do, if you are insane, how do you know? I don't know how a router would know this, or determine it.. unless some protocol it's speaking gives it time-hints. Would it be appropriate to hack in a timehack to the rkpi-rtr protocol? (featurecreeper!) > =A0 SHOULD NOT attempt to validate incoming updates. =A0It SHOULD defer > =A0 validation until it believes it is within reasonable time tolerance. > > =A0 Servers SHOULD provide time service, such as NTP [RFC5905], to client > =A0 routers. it seems that 'SHOULD' here may lead into forcing (or appearing to force) ops to do something they don't already do (or perhaps wouldn't want to do... jigsaw with logs is fun!), maybe that's what's gotten at least terry's attention? -Chris From randy@psg.com Mon Apr 25 22:45:12 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D2AE0707 for ; Mon, 25 Apr 2011 22:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.924 X-Spam-Level: X-Spam-Status: No, score=-4.924 tagged_above=-999 required=5 tests=[AWL=1.675, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLFVMSGNcnt1 for ; Mon, 25 Apr 2011 22:45:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0D4E06F8 for ; Mon, 25 Apr 2011 22:45:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QEb5D-000Htv-9K; Tue, 26 Apr 2011 05:45:11 +0000 Date: Tue, 26 Apr 2011 14:45:56 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:45:12 -0000 >> =A0 As a router must evaluate certificates and ROAs which are time >> =A0 dependent, routers' clocks MUST be correct to a tolerance of >> =A0 approximately an hour. > does there need to be a 'why' for the 'approximately an hour'? (like: > "since granularity of cert time-to-live's is 30 mins on the minimum > side" ... wordsmith or whatever as appropriate) because rpki processing cycles are likely to be of that tolerance. but do we really want to go down this path? >> =A0 If a router has reason to believe its clock is seriouly incorrect, it > 'has reason to believe' ... seems hard to do i suggested two well-know ways and got nit picked within 42 seconds. i would be happy to put the examples, 1970 and 2005, back. but they are just lint attractors. > Would it be appropriate to hack in a timehack to the rkpi-rtr > protocol? (featurecreeper!) no. we will not reinvent time synchronization. >> =A0 Servers SHOULD provide time service, such as NTP [RFC5905], to client >> =A0 routers. > it seems that 'SHOULD' here may lead into forcing (or appearing to > force)=20 SHOULD !=3D MUST randy From Jac.Kloots@surfnet.nl Tue Apr 26 00:25:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7677CE0719 for ; Tue, 26 Apr 2011 00:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L64pf7DsLVQ4 for ; Tue, 26 Apr 2011 00:25:08 -0700 (PDT) Received: from ms1.zimbra.surfnet.nl (ms1.zimbra.surfnet.nl [192.87.108.8]) by ietfa.amsl.com (Postfix) with ESMTP id DD6A3E070A for ; Tue, 26 Apr 2011 00:25:06 -0700 (PDT) Received: from hello.surfnet.nl (hello.surfnet.nl [192.87.109.146]) by ms1.zimbra.surfnet.nl (Postfix) with ESMTPSA id 282E219A728; Tue, 26 Apr 2011 09:25:05 +0200 (CEST) Date: Tue, 26 Apr 2011 09:25:11 +0200 (CEST) From: Jac Kloots X-X-Sender: kloots@hello.surfnet.nl To: Randy Bush In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-762625880-1303802713=:28227" Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 07:25:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-762625880-1303802713=:28227 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Randy, Others, It doesn't seem to be a new problem to me. How is this time problem evaluated in the current off-line cache software? Why think of another approach if the only difference is the device doing the validation of certs and ROA's? Regards, Jac On Tue, 26 Apr 2011, Randy Bush wrote: >>>   As a router must evaluate certificates and ROAs which are time >>>   dependent, routers' clocks MUST be correct to a tolerance of >>>   approximately an hour. >> does there need to be a 'why' for the 'approximately an hour'? (like: >> "since granularity of cert time-to-live's is 30 mins on the minimum >> side" ... wordsmith or whatever as appropriate) > > because rpki processing cycles are likely to be of that tolerance. but > do we really want to go down this path? > >>>   If a router has reason to believe its clock is seriouly incorrect, it >> 'has reason to believe' ... seems hard to do > > i suggested two well-know ways and got nit picked within 42 seconds. i > would be happy to put the examples, 1970 and 2005, back. but they are > just lint attractors. > >> Would it be appropriate to hack in a timehack to the rkpi-rtr >> protocol? (featurecreeper!) > > no. we will not reinvent time synchronization. > >>>   Servers SHOULD provide time service, such as NTP [RFC5905], to client >>>   routers. >> it seems that 'SHOULD' here may lead into forcing (or appearing to >> force) > > SHOULD != MUST > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > -- Jac Kloots Network Services SURFnet bv --0-762625880-1303802713=:28227-- From randy@psg.com Tue Apr 26 00:42:56 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC19E0703 for ; Tue, 26 Apr 2011 00:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.023 X-Spam-Level: X-Spam-Status: No, score=-5.023 tagged_above=-999 required=5 tests=[AWL=1.576, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxymsUB44zfG for ; Tue, 26 Apr 2011 00:42:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id D7B5AE067C for ; Tue, 26 Apr 2011 00:42:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QEcts-000IEN-Gc; Tue, 26 Apr 2011 07:41:36 +0000 Date: Tue, 26 Apr 2011 16:42:22 +0900 Message-ID: From: Randy Bush To: Jac Kloots In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 07:42:56 -0000 > It doesn't seem to be a new problem to me. How is this time problem > evaluated in the current off-line cache software? from draft-ietf-sidr-rpki-rtr As a cache server must evaluate certificates and ROAs which are time dependent, servers' clocks MUST be correct to a tolerance of approximately an hour. > Why think of another approach if the only difference is the device > doing the validation of certs and ROA's? same approach. just trying to throw in a bit more detail for two reasons o brian beat me up o in bgpsec, the router might not validate but still sign and pass on. it is signing to attest to "i saw this" not that it believed it. subtle. randy From Jac.Kloots@surfnet.nl Tue Apr 26 01:53:40 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0ADCE069A for ; Tue, 26 Apr 2011 01:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgbffBB7tczj for ; Tue, 26 Apr 2011 01:53:40 -0700 (PDT) Received: from ms1.zimbra.surfnet.nl (ms1.zimbra.surfnet.nl [192.87.108.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8D6E0676 for ; Tue, 26 Apr 2011 01:53:39 -0700 (PDT) Received: from hello.surfnet.nl (hello.surfnet.nl [192.87.109.146]) by ms1.zimbra.surfnet.nl (Postfix) with ESMTPSA id BFF6A19A728; Tue, 26 Apr 2011 10:53:37 +0200 (CEST) Date: Tue, 26 Apr 2011 10:53:45 +0200 (CEST) From: Jac Kloots X-X-Sender: kloots@hello.surfnet.nl To: Randy Bush In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 08:53:40 -0000 Randy, On Tue, 26 Apr 2011, Randy Bush wrote: >> It doesn't seem to be a new problem to me. How is this time problem >> evaluated in the current off-line cache software? > > from draft-ietf-sidr-rpki-rtr > > As a cache server must evaluate certificates and ROAs which are time > dependent, servers' clocks MUST be correct to a tolerance of > approximately an hour. > >> Why think of another approach if the only difference is the device >> doing the validation of certs and ROA's? > > same approach. just trying to throw in a bit more detail for two > reasons If it is the same approach, why detail this more? It is a MUST time settings are correct, and let router vendors take care of the 'tolerance of approximately an hour' implementation. Beside this, I just read the draft-ymbk-bgpsec-ops draft and the detail you're now trying to get into the document seems a bit odd to me. I think the time-issues should be noted where validation is described and that operational considerations aren't the right place for this. Jac > o brian beat me up > > o in bgpsec, the router might not validate but still sign and pass on. > it is signing to attest to "i saw this" not that it believed it. > subtle. > > randy > -- Jac Kloots Network Services SURFnet bv From randy@psg.com Tue Apr 26 03:41:34 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24227E0725 for ; Tue, 26 Apr 2011 03:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.068 X-Spam-Level: X-Spam-Status: No, score=-5.068 tagged_above=-999 required=5 tests=[AWL=1.531, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m2OKPH+9Y67 for ; Tue, 26 Apr 2011 03:41:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 7E51FE0723 for ; Tue, 26 Apr 2011 03:41:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QEfgl-000IjC-Bg; Tue, 26 Apr 2011 10:40:15 +0000 Date: Tue, 26 Apr 2011 19:41:01 +0900 Message-ID: From: Randy Bush To: Jac Kloots In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 10:41:34 -0000 >>> It doesn't seem to be a new problem to me. How is this time problem >>> evaluated in the current off-line cache software? >> >> from draft-ietf-sidr-rpki-rtr >> >> As a cache server must evaluate certificates and ROAs which are time >> dependent, servers' clocks MUST be correct to a tolerance of >> approximately an hour. >> >>> Why think of another approach if the only difference is the device >>> doing the validation of certs and ROA's? >> >> same approach. just trying to throw in a bit more detail for two >> reasons > > If it is the same approach, why detail this more? It is a MUST time > settings are correct, and let router vendors take care of the > 'tolerance of approximately an hour' implementation. > > Beside this, I just read the draft-ymbk-bgpsec-ops draft and the > detail you're now trying to get into the document seems a bit odd to > me. > > I think the time-issues should be noted where validation is described > and that operational considerations aren't the right place for this. hi jac, i am not sure i am really getting your point(s), so i may be way off here. but let me give it a go. we're talking two very different protocol/security/document sets here. o draft-ietf-sidr-rpki-rtr is for origin validation, and goes with draft-ietf-sidr-origin-ops, and the router never sees certs or anything else which requires the router to know anything about time. it's all in the cache servers which feed only highly digested data to the routers. o draft-ymbk-bgpsec-ops goes with draft-lepinski-bgpsec-overview and draft-lepinski-bgpsec-protocol, where certs et alia go all the way to the routers, and hence the routers need to know time. and brian questioned if and how they might be trusted to know something about what time it is. while i could imagine a doc which covers operational considerations for anything validating rpki data, this would not cover that bgpsec has signatures with expiry times in the bgp messages, which are outside of the rpki. i guess we could ask matt to go into more detail about validation and time in draft-lepinski-bgpsec-protocol. when we designed the bgpsec docco set, i got the tasks of this level of dregs. and that would not cover slack in validation of the rpki data. if you have the stomach to read the idr list, i doubt you really want to leave too much leeway for misinterpretation by bgp implementers. they have the grand prize for twisty minded nit pickers. we are amateurs. randy From Wesley.E.George@sprint.com Tue Apr 26 06:53:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB739E07A5 for ; Tue, 26 Apr 2011 06:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.281 X-Spam-Level: X-Spam-Status: No, score=-5.281 tagged_above=-999 required=5 tests=[AWL=1.318, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IimL+PVeVH9G for ; Tue, 26 Apr 2011 06:53:44 -0700 (PDT) Received: from VA3EHSOBE009.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADC2E079F for ; Tue, 26 Apr 2011 06:53:44 -0700 (PDT) Received: from mail11-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.8; Tue, 26 Apr 2011 13:53:43 +0000 Received: from mail11-va3 (localhost.localdomain [127.0.0.1]) by mail11-va3-R.bigfish.com (Postfix) with ESMTP id 62B5CB1811E; Tue, 26 Apr 2011 13:53:43 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371O542Mzz1202hzz8275dh1033ILz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI Received: from mail11-va3 (localhost.localdomain [127.0.0.1]) by mail11-va3 (MessageSwitch) id 1303826023165747_16263; Tue, 26 Apr 2011 13:53:43 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.243]) by mail11-va3.bigfish.com (Postfix) with ESMTP id 24882E80052; Tue, 26 Apr 2011 13:53:43 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 26 Apr 2011 13:53:39 +0000 Received: from PDAWEH03.ad.sprint.com (PDAWEH03.corp.sprint.com [144.226.110.91]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p3QDrbNC003444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Apr 2011 08:53:38 -0500 Received: from PDAWM12B.ad.sprint.com ([fe80::64c8:fd69:1029:79b0]) by PDAWEH03.ad.sprint.com ([2002:90e2:6e5b::90e2:6e5b]) with mapi id 14.01.0270.001; Tue, 26 Apr 2011 08:53:37 -0500 From: "George, Wes E [NTK]" To: Randy Bush , Christopher Morrow Thread-Topic: [sidr] time Thread-Index: AQHMA72T+MkrzpBC5UOPOdG34+rCeJRv0SUAgAAhPwCAAALDgIAAAZwAgAAwPXA= Date: Tue, 26 Apr 2011 13:53:37 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8A3BB@PDAWM12B.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.26] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001A_01CC03F7.D0624B90" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:53:45 -0000 ------=_NextPart_000_001A_01CC03F7.D0624B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of = Randy Bush Sent: Tuesday, April 26, 2011 1:46 AM To: Christopher Morrow Cc: sidr wg list Subject: Re: [sidr] time >> =A0 If a router has reason to believe its clock is seriouly = incorrect,=20 >> it > 'has reason to believe' ... seems hard to do i suggested two well-know ways and got nit picked within 42 seconds. i = would be happy to put the examples, 1970 and 2005, back. but they are just lint attractors. [WEG] I think you can make the implementation recommendation for = defining "seriously incorrect" without being specific - that is, "if current clock value is near the known default 'unset clock value' = for the particular implementation..." Most people will infer from that, "if unix && time =3D 1970, then BORKED()" and it leaves the = implementation to the vendor, who will know their own default time value. All you'd need to do is define what value of near default is = considered broken. [snip from another msg] > If you're more than a few years off from the latest ROA issuance=20 > dates, then you're probably bogus. Say, take the average issuance of=20 > the most recent 100 ROAs and see if you're more than 5 years off. a good example of how complexity opens attack vectors [WEG] I'm curious what the attack vector for the proposed solution of = using contextual clues to determine that your clock is wrong would be. If you're saying "look at NNN updates and if your clock is = more than $timevalue off from the dates, your clock is wrong" Shouldn't the risk of someone intentionally sending updates with weird = timestamps to trick the router into thinking that its clock is wrong and cease validation be dramatically reduced with an acceptable = sample size? But beyond that, aren't any of these proposals simply attempts at = over-complicating things? I still say we should just require NTP and be done with it. Then you could say, if you lose connection with an = NTP for more than $time, you MUST cease validation until NTP is restored. You could make the value appropriately generous, and then = vendors could allow a knob to reduce the value for people who are confident in their NTP config and connectivity. Wes George ------=_NextPart_000_001A_01CC03F7.D0624B90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQyNjEz NTMzN1owIwYJKoZIhvcNAQkEMRYEFJ3ZHY7719v5C6Qlq+RvFcZJ6/KlMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgBuEQwxCowf2eQGKrQpOveZ5nzw2KxsuFePkW8m8iScDKyFmzJtyIf0aQNTQ4V1tPDLl V17UsVK9aRKfJ3e1CZKYe6hZePasF3RFTm80xRzveUm9oFHdYvgPaD1NVy/Se12colcYFeVklXuW 54tD/otvNLNZFsaJfNh5mCOXoF4gAAAAAAAA ------=_NextPart_000_001A_01CC03F7.D0624B90-- From randy@psg.com Tue Apr 26 07:11:42 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E671E07B5 for ; Tue, 26 Apr 2011 07:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[AWL=1.489, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbemvL+DCOjA for ; Tue, 26 Apr 2011 07:11:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id F22DBE06A8 for ; Tue, 26 Apr 2011 07:11:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QEiy7-000JPR-2N; Tue, 26 Apr 2011 14:10:23 +0000 Date: Tue, 26 Apr 2011 23:11:09 +0900 Message-ID: From: Randy Bush To: "George, Wes E [NTK]" In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8A3BB@PDAWM12B.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8A3BB@PDAWM12B.ad.sprint.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 14:11:42 -0000 > All you'd need to do is define what value of near default is > considered broken. how about earlier than 2011? >> If you're more than a few years off from the latest ROA issuance >> dates, then you're probably bogus. Say, take the average issuance of >> the most recent 100 ROAs and see if you're more than 5 years off. > a good example of how complexity opens attack vectors > > [WEG] I'm curious what the attack vector for the proposed solution of > using contextual clues to determine that your clock is wrong would > be. If you're saying "look at NNN updates and if your clock is more > than $timevalue off from the dates, your clock is wrong" Shouldn't the > risk of someone intentionally sending updates with weird timestamps to > trick the router into thinking that its clock is wrong and cease > validation be dramatically reduced with an acceptable sample size? more complexity > But beyond that, aren't any of these proposals simply attempts at > over-complicating things? I still say we should just require NTP and > be done with it. Then you could say, if you lose connection with an > NTP for more than $time, you MUST cease validation until NTP is > restored. You could make the value appropriately generous, and then > vendors could allow a knob to reduce the value for people who are > confident in their NTP config and connectivity. i am not sure one can assume universal ntp availability. but your particular phrasing does not take start-up into account. not a big problem, but more word nitpicking to be done. randy From ietfc@btconnect.com Thu Apr 28 07:29:22 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39961E06F5 for ; Thu, 28 Apr 2011 07:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuhpIQQCuYeq for ; Thu, 28 Apr 2011 07:29:21 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id 23A20E0669 for ; Thu, 28 Apr 2011 07:29:04 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2beaomr08.btconnect.com with SMTP id CPT79001; Thu, 28 Apr 2011 15:28:44 +0100 (BST) Message-ID: <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Joe Touch" References: <4DAF44AC.8060408@isi.edu><4DAF796C.7010807@isi.edu><409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> Date: Thu, 28 Apr 2011 15:27:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Poor-1, source=Queried, refid=tid=0001.0A0B0303.4DB9799C.0030, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4DB9799E.010D,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 14:29:22 -0000 ----- Original Message ----- From: "Joe Touch" To: "t.petch" Cc: "Christopher Morrow" ; "sidr wg list" Sent: Monday, April 25, 2011 5:26 PM > Hi, Tom, > > On 4/25/2011 1:47 AM, t.petch wrote: > .... > > I think that the point is not that it is or is not a BGP connection > > but that security for BGP was predicated on the assumption that > > the TCP connection would be short in terms of hops, ie none, > > and it was that that made a less stringent approach to security > > acceptable, one that would not be acceptable for an Internet > > wide access for - say - a Web site. > > Hopcount security, i.e., GTSM (RFC 3682) is not at all related to TCP-AO. Understood; I was thinking of RFC4278 which calls out the unusual nature of BGP sessions and the impact on security requirements. I am familiar with TCP-AO from the TCPM list, but am not enough of a cryptanalyst to know whether or not it is appropriate for rpki-rtr. By contrast, I have seen SSH and TLS discussed much more extensively on their lists and have been part of the pain of adding them to syslog and SNMP. And I do not know where these rpki-rtr sessions will go to and from but suspect that they will not be BGP-like. Tom Petch > TCP-AO provides replay protection, includes extended sequence numbers to > account for seqno rollover, and support for changing keys during a > connection without impact to TCP. It also uses per-connection keys > derived from master keys. > > > What I am missing is not whether or not this is BGP, but > > whether or not the connection will have the properties of > > BGP, of being very short. My suspicion is that the > > data will be coming from all over the place, Internet-wide > > (as with CRL) and so the security should be Web-like and not > > BGP-like; ie TCP-AO will not do. > > I encourage you to take another look at TCP-AO; there is nothing therein > that is focused exclusively on any property of BGP. It was intended as a > generic mechanism to support transport authentication for TCP connections. > > Joe From touch@isi.edu Thu Apr 28 10:31:48 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DEFE06CE for ; Thu, 28 Apr 2011 10:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnrrLNuA9of6 for ; Thu, 28 Apr 2011 10:31:42 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfa.amsl.com (Postfix) with ESMTP id A9C48E069A for ; Thu, 28 Apr 2011 10:31:42 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p3SHV2R1026477 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 28 Apr 2011 10:31:03 -0700 (PDT) Message-ID: <4DB9A456.3060709@isi.edu> Date: Thu, 28 Apr 2011 10:31:02 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "t.petch" References: <4DAF44AC.8060408@isi.edu><4DAF796C.7010807@isi.edu><409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> In-Reply-To: <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p3SHV2R1026477 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 17:31:48 -0000 On 4/28/2011 6:27 AM, t.petch wrote: > ----- Original Message ----- > From: "Joe Touch" > To: "t.petch" > Cc: "Christopher Morrow"; "sidr wg list" > > Sent: Monday, April 25, 2011 5:26 PM > >> Hi, Tom, >> >> On 4/25/2011 1:47 AM, t.petch wrote: >> .... >>> I think that the point is not that it is or is not a BGP connection >>> but that security for BGP was predicated on the assumption that >>> the TCP connection would be short in terms of hops, ie none, >>> and it was that that made a less stringent approach to security >>> acceptable, one that would not be acceptable for an Internet >>> wide access for - say - a Web site. >> >> Hopcount security, i.e., GTSM (RFC 3682) is not at all related to TCP-AO. > > Understood; I was thinking of RFC4278 which calls out the unusual nature of > BGP sessions and the impact on security requirements. That document explains why TCP MD5 was considered appropriate for BGP, given the variance in the maturity level of the standards of the two docs. TCP-AO has no such assertions or qualifications. It is a general purpose mechanism that includes some properties useful for BGP, but that are also very relevant to exchanges between clients and caches as well. > I am familiar with TCP-AO from the TCPM list, but am not enough of a > cryptanalyst to know whether or not it is appropriate for rpki-rtr. > > By contrast, I have seen SSH and TLS discussed much more extensively > on their lists and have been part of the pain of adding them to syslog and > SNMP. > > And I do not know where these rpki-rtr sessions will go to and from but > suspect that they will not be BGP-like. BGP-like presumably means: - long lived - between known endpoints - over short IP hops Of these, only "long lived" had any impact on the TCP-AO design. Of these, any can be relevant to rpki-rtr sessions, from the traffic I've seen on this list. Keying is another relevant issue; configuration of SSH and TLS for pre-shared keys is different than for TCP MD5 (and TCP-AO, which uses similar master keys), and not the typical case. My point is that TCP-AO wasn't designed for BGP; it was designed as a general purpose mechanism. Joe From foahmed@cisco.com Fri Apr 29 17:40:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612E7E06AD for ; Fri, 29 Apr 2011 17:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myPGAZhoA2rv for ; Fri, 29 Apr 2011 17:40:18 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id AA00AE0677 for ; Fri, 29 Apr 2011 17:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=foahmed@cisco.com; l=5943; q=dns/txt; s=iport; t=1304124018; x=1305333618; h=mime-version:subject:date:message-id:from:to:cc; bh=ZI05eDxt0Ej+m/uGgdg3q5XAapHn7QCOSisY51oqmxU=; b=lgmTu9osvqnrTCPcf26xwQf+gu6wfOVx03462hvY+QjtNdEA+gCil2ij rPnLX9u4lEEVOfbaYzMhfmFskyCvEytfAcf6lSdbhy5EO2wLXKtOjP1ny oIYnfoBaOudW80KrsLnhX5V8FlDXxv+HR9knlVzUdGZWCdoS6IBRUCMm4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0HAFBZu02rRDoJ/2dsb2JhbACCYZVwjUF3qECcTIV+BIYNjHuKGg X-IronPort-AV: E=Sophos;i="4.64,291,1301875200"; d="scan'208,217";a="347578318" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2011 00:40:18 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3U0eIcK018853; Sat, 30 Apr 2011 00:40:18 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Apr 2011 17:40:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC06CF.2DAAD7BC" Date: Fri, 29 Apr 2011 17:40:18 -0700 Message-ID: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rpki-rtr protocol maximum message length Thread-Index: AcwGz/MiT4ALE9WVQImKYdYOTvkHzw== From: "Forhad Ahmed (foahmed)" To: X-OriginalArrivalTime: 30 Apr 2011 00:40:18.0407 (UTC) FILETIME=[2DD89F70:01CC06CF] Subject: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 00:40:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC06CF.2DAAD7BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Most of the messages in the protocol are nice and small messages, but the error-report message can be of arbitrary size since it can have trailing diagnostic text... Can we specify a maximum value for length of this message? A cache implementation can send a huge amount of diagnostic text in an error-report message and have it still be a valid message for the router to parse... It should be capped at a few K. =20 -Forhad ------_=_NextPart_001_01CC06CF.2DAAD7BC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Most of the messages in the protocol are nice and = small messages, but the error-report message can be of arbitrary size since it = can have trailing diagnostic text…


Can we specify a maximum value for length of this message?  A cache = implementation can send a huge amount of diagnostic text in an error-report message and = have it still be  a valid message for the router to parse… =  It should be capped at a few K.

 

-Forhad

------_=_NextPart_001_01CC06CF.2DAAD7BC-- From raszuk@cisco.com Sat Apr 30 03:24:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94D5E06CA for ; Sat, 30 Apr 2011 03:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVGueSseIy0J for ; Sat, 30 Apr 2011 03:24:13 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 306DAE06F3 for ; Sat, 30 Apr 2011 03:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1030; q=dns/txt; s=iport; t=1304159053; x=1305368653; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=LOaQU1ful7B2qwnTTfUdCGZVePLYXC6ntVqOBHMGeZQ=; b=I6/6ywn7dnQGl0Wo6T/KTjhwAFiBwKOUTaRsyWWoNY/ktXfDAYUhnKHo GnkSBhRKA3bg6d8m1BmH6t993LwyimMlQSoAFh/4qiglCFw72BsKASqAi SA7aU1BJBqmWNHu+AoCKtHDVhbNhmqKfrW+N3zM8JRdBlhXW1y3HBYRxe Y=; X-IronPort-AV: E=Sophos;i="4.64,292,1301875200"; d="scan'208";a="439349433" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 30 Apr 2011 10:24:10 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3UAO9H4030422; Sat, 30 Apr 2011 10:24:10 GMT Message-ID: <4DBBE34D.3050507@cisco.com> Date: Sat, 30 Apr 2011 12:24:13 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Forhad Ahmed (foahmed)" , sidr@ietf.org References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> In-Reply-To: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: raszuk@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 10:24:13 -0000 Hi Forhad, I think defining max length of maybe not error-report itself, but actually max of "Length of Error Text" field would be nice to size the space for this in the implementation. Good catch. -- And while we are here .. is this a copy and paste error that section 5.6 in IPv6 prefix PDU definition allows only 0..32 min prefix length for IPv6 prefix ? Can't I specify 64 as min length prefix for example ? Thx, R. > Most of the messages in the protocol are nice and small messages, but > the error-report message can be of arbitrary size since it can have > trailing diagnostic text… > > Can we specify a maximum value for length of this message? A cache > implementation can send a huge amount of diagnostic text in an > error-report message and have it still be a valid message for the router > to parse… It should be capped at a few K. > > -Forhad > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Sat Apr 30 23:15:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9AFE0689 for ; Sat, 30 Apr 2011 23:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.225 X-Spam-Level: X-Spam-Status: No, score=-5.225 tagged_above=-999 required=5 tests=[AWL=1.374, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-bUz9gwPOiK for ; Sat, 30 Apr 2011 23:15:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 6407FE0651 for ; Sat, 30 Apr 2011 23:15:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QGPuk-0006Au-JY; Sun, 01 May 2011 06:13:55 +0000 Date: Sun, 01 May 2011 08:14:53 +0200 Message-ID: From: Randy Bush To: "Forhad Ahmed (foahmed)" In-Reply-To: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> References: <8A7BEFB8FCD25A43BB73B1D879B82F770457B0AF@xmb-sjc-239.amer.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] rpki-rtr protocol maximum message length X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 06:15:13 -0000 > Most of the messages in the protocol are nice and small messages, but > the error-report message can be of arbitrary size since it can have > trailing diagnostic text... > > Can we specify a maximum value for length of this message? A cache > implementation can send a huge amount of diagnostic text in an > error-report message and have it still be a valid message for the > router to parse... It should be capped at a few K. the longest non-error pdu is pdu 6, the ipv6 pdu. this limits the max size error pdu to a fairly small size. randy