From pmohapat@cisco.com Sun Aug 1 23:20:06 2010 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 05BF33A67D4 for ; Sun, 1 Aug 2010 23:20:06 -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 LTWn+h2G01T8 for ; Sun, 1 Aug 2010 23:20:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 28B6E3A67C0 for ; Sun, 1 Aug 2010 23:20:05 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHgAVkyrR7H+/2dsb2JhbACgEHGkYpowhTkEhBaEaQ X-IronPort-AV: E=Sophos;i="4.55,301,1278288000"; d="scan'208";a="233933279" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 02 Aug 2010 06:20:32 +0000 Received: from sjc-vpn6-84.cisco.com (sjc-vpn6-84.cisco.com [10.21.120.84]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o726KWsS029368; Mon, 2 Aug 2010 06:20:32 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: <20100729135023.GD19401@slice> Date: Sun, 1 Aug 2010 23:20:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <071667FC-D672-4F81-BB2C-704C33CF709A@cisco.com> References: <20100729135023.GD19401@slice> To: Jeffrey Haas X-Mailer: Apple Mail (2.1077) Cc: "Sriram, Kotikalapudi" , sidr@ietf.org Subject: Re: [sidr] Comment about aggregators and AS_SETs 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, 02 Aug 2010 06:20:06 -0000 I support Jeff's proposal for matching the "first AS after AS_SET" with = the=20 [AS4_]AGGREGATOR attribute. If I understand correctly, the suggestion is = to follow the below algorithm for deriving origin_as: 1. origin_as =3D rightmost AS in the final AS_SEQUENCE of the AS_PATH = attribute 2. If the UPDATE carries [AS4_]AGGREGATOR and AS_SET attributes if (first AS after AS_SET =3D=3D AS encoded in = [AS4_]AGGREGATOR), then origin_as =3D first AS after AS_SET else origin_as =3D NONE Sriram, a quick question on your enumeration tree: the right hand side = in the tree starts with "No AS_SET", but later you have nodes that say "Matches the = first AS after AS_SET"... What does that mean? Also, IMO, the attack vector you = mention in the slides are more related to path validation than origin = validation. - Pradosh= From jhaas@slice.pfrc.org Mon Aug 2 09:03:21 2010 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 3BCAD3A6926 for ; Mon, 2 Aug 2010 09:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.571 X-Spam-Level: X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU7cxkR8fdvy for ; Mon, 2 Aug 2010 09:03:20 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id F2C773A68E0 for ; Mon, 2 Aug 2010 09:03:19 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B24D6224337; Mon, 2 Aug 2010 16:03:47 +0000 (UTC) Date: Mon, 2 Aug 2010 16:03:47 +0000 From: Jeffrey Haas To: Pradosh Mohapatra Message-ID: <20100802160347.GA10812@slice> References: <20100729135023.GD19401@slice> <071667FC-D672-4F81-BB2C-704C33CF709A@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <071667FC-D672-4F81-BB2C-704C33CF709A@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sidr@ietf.org Subject: Re: [sidr] Comment about aggregators and AS_SETs 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, 02 Aug 2010 16:03:21 -0000 On Sun, Aug 01, 2010 at 11:20:48PM -0700, Pradosh Mohapatra wrote: > I support Jeff's proposal for matching the "first AS after AS_SET" with the > [AS4_]AGGREGATOR attribute. Just to be clear, this is Sriram's proposal. I'm just suggesting some additional language for protocol clarity. :-) > If I understand correctly, the suggestion is to > follow the below algorithm for deriving origin_as: > > 1. origin_as = rightmost AS in the final AS_SEQUENCE of the AS_PATH attribute > 2. If the UPDATE carries [AS4_]AGGREGATOR and AS_SET attributes > if (first AS after AS_SET == AS encoded in [AS4_]AGGREGATOR), then > origin_as = first AS after AS_SET > else > origin_as = NONE Since this has come up again, let's try to formalize this according to RFC 4271 AS_PATH semantics. RFC 4271, section 5.1.2 provides the context of "left" and "right" with regard to the AS_PATH. -------8<---- cut here ---->8------- 0. In the presence of the RFC 4893 AS4_PATH path attribute, the AS_PATH SHALL first be reconstructed per RFC 4893 rules. If the AS_PATH cannot be successfully re-constructed or there is structural or semantic ambiguity with regard to AS numbers or path segment types, the origin AS SHALL be treated as None. 1. If the AS_PATH segment types solely consist of confederation segment types, then the origin AS SHALL be treated as Local. 2. If there is no segment type of AS_SEQUENCE, then the origin AS SHALL be treated as None. 3. If the rightmost path segment type is AS_SEQUENCE, then the origin AS SHALL be the rightmost AS in the AS_PATH. 4. If the rightmost path segment type is NOT an AS_SEQUENCE, then locate the rightmost path segment of type AS_SEQUENCE. If an AGGREGATOR path attribute is present, including the reconstructed AGGREGATOR per RFC 4893 rules, and the rightmost AS of the rightmost path segment of type AS_SEQUENCE matches the AGGREGATOR AS, then this AS SHALL be treated as the origin AS. If the rightmost AS of the rightmost path segment of type AS_SEQUENCE does not match the AGGREGATOR AS, then the origin AS SHALL be treated as None. If no AGGREGATOR path attribute is present, then the rightmost AS of the rightmost path segment of type AS_SEQUENCE MAY be treated as the origin AS. -------8<---- cut here ---->8------- (Renumber the base as you feel appropriate.) Discussion: 4-byte ASes (RFC 4893) introduces some interesting headaches for purposes of choosing our AS for origin validation. In the simplest possible case, we must always reconstruct the path according to the rules prior to choosing the origin AS. If we fail reconstruction (more on that below), then we probably shouldn't use the original AS_PATH for purposes of doing origin authentication. Our two malicious cases when reconstruction fails are that the AS_PATH has been tampered with but that the AS4_PATH is correct or vice-versa. Our non-malicious case has to do with ambiguities in RFC 4893 that should probably be clarified prior to placing a dependency on this mechanism for origin validation. The problem comes with the rules for reconstruction: : If the number of AS numbers in the AS_PATH attribute is larger than : or equal to the number of AS numbers in the AS4_PATH attribute, then : the AS path information SHALL be constructed by taking as many AS : numbers and path segments as necessary from the leading part of the : AS_PATH attribute, and then prepending them to the AS4_PATH attribute : so that the AS path information has an identical number of AS numbers : as the AS_PATH attribute. Effectively this says that you ignore mis-matches in the ASes. E.g. AS_PATH: 1 2 3 4 AS4_PATH: 3 7 Similarly, the RFC is unclear about the case when the ASes are correct but the structural semantics don't match: AS_PATH: 1 2 3 4 AS4_PATH: [3 4] I don't intend to try to drive clarification of RFC 4893 within SIDR - I owe my comments to the author of the -bis document in IDR. However, I would suggest that this clarification is an important issue for SIDR and should be monitored. An additional point that John Scudder had pointed out to me is that valid "brief" AS_PATH aggregation may yield an AS_PATH and an AGGREGATOR where the above rules would fail. E.g.: AS_PATH1: 1 2 3 AS_PATH2: 1 4 5 Aggregated path: 1 [2 3 4 5] If AS 100 is the aggregating AS, then the AGGREGATOR AS will not match the right-most AS. Sriram's analysis of existing BGP routing data shows that this isn't problematic. I would recommend that this case should be documented for completeness. -- Jeff From tim@ripe.net Wed Aug 4 01:09:34 2010 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 19DF73A6A1B for ; Wed, 4 Aug 2010 01:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.54 X-Spam-Level: X-Spam-Status: No, score=-1.54 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_05=-1.11] 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 BBEZLirDmUu4 for ; Wed, 4 Aug 2010 01:09:33 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id A18643A6847 for ; Wed, 4 Aug 2010 01:09:32 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OgZ2x-0000oR-06 for sidr@ietf.org; Wed, 04 Aug 2010 10:10:00 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-110.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OgZ2w-0001YS-RS for sidr@ietf.org; Wed, 04 Aug 2010 10:09:54 +0200 Message-ID: <4C592052.50903@ripe.net> Date: Wed, 04 Aug 2010 10:09:54 +0200 From: Tim Bruijnzeels User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: sidr@ietf.org References: <20100614152202.621B922808@thrintun.hactrn.net> <4C17D109.9070705@ieca.com> <4C17D82F.4080105@nist.gov> <4C3332B2.802@ripe.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719fc2649215c63be88c17d2d28151d1b12 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719fc2649215c63be88c17d2d28151d1b12 Subject: Re: [sidr] key rollover and algorithm migration 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, 04 Aug 2010 08:09:34 -0000 Hi, On 7/26/10 9:59 AM, Geoff Huston wrote: > > On 14/07/2010, at 12:36 PM, Geoff Huston wrote: > >>>> - Key roll-over algorithm >>>> >>>> Our software currently implements a specific way to do roll-overs. At >>>> the time we implemented this it wasn't 100% clear to us how this >>>> *should* be done, and indeed whether there should be some prescribed way >>>> to do this. >>> >>> I believe that we need to have a single, prescribed way to do this; each CA needs to know what is expected of it by its subordinate CAs and by all RPs. I believe we should have a separate document that clearly articulates what a CA is required to do. There are CA-local aspects to this procedure, as Geoff's text notes. The parameters for those belong in the CPS for the CA. The current description is not normative and I think that needs to change. >>> >> >> >> You are proposing that the procedure as described in section 8 of draft-ietf-sidr-res-certs-18.txt be placed into a normative form in its own document? > > > In collaboration with George Michaelson and Steve Kent, we have lifted out section 8 of draft-ietf-sidr-res-certs-18.txt and placed into a normative form in its own document. This is in the drafts repository as draft-huston-sidr-keyroll-00.txt. > > I would like to request via the WG chairs that the WG adopt this document as a WG document. I am not sure what the procedure is, but I'd like to +1 this for adoption. Cheers Tim From jhaas@slice.pfrc.org Wed Aug 4 08:24:14 2010 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 899623A68E8 for ; Wed, 4 Aug 2010 08:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B5c6ABSvK+p for ; Wed, 4 Aug 2010 08:24:13 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 9B3D43A6823 for ; Wed, 4 Aug 2010 08:24:13 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 26AC72251E4; Wed, 4 Aug 2010 15:24:43 +0000 (UTC) Date: Wed, 4 Aug 2010 15:24:43 +0000 From: Jeffrey Haas To: sidr@ietf.org Message-ID: <20100804152443.GA25173@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] Comments on draft-pmohapat-sidr-origin-validation-signaling 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, 04 Aug 2010 15:24:14 -0000 In addition to the energetic discussion about the terminology for the three states of the community, I'd also like to suggest that the origin of the validation may be relevant. The cache protocol gives a data source for the validation and that source probably should be represented within this community. This also argues that it may be reasonable to have multiple instances of this community - or that the representation of the data source should be a bit-vector. I also wonder if "color" would need to go into a community such as this one. Since the current purpose of "color" is unclear, it's hard to know one way or the other. The above has impact on the suggested changes to the BGP decision process. For example, an operator may prefer that RPKI validation have precedence over IRR validation. Similarly, "color" may impact it. -- Jeff From jhaas@slice.pfrc.org Wed Aug 4 08:38:54 2010 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 B1BEE3A6BF6 for ; Wed, 4 Aug 2010 08:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br-pIlGRrHSv for ; Wed, 4 Aug 2010 08:38:30 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 6882F3A6BAA for ; Wed, 4 Aug 2010 08:36:24 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 839082251DF; Wed, 4 Aug 2010 15:33:22 +0000 (UTC) Date: Wed, 4 Aug 2010 15:33:22 +0000 From: Jeffrey Haas To: sidr@ietf.org Message-ID: <20100804153322.GB25173@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] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 15:38:54 -0000 Could the authors comment on the expected behavior of a single router with a pair of sessions to cache servers operated by the same provider which implement the same RPKI policy? The use-case I have in mind is that a given provider may have a number of cache servers deployed within their network. A given router may wish to have a session with two servers for redundancy purposes. Given the current protocol, the best a router can do is know that it has all of the records from a given cache server. There is no way to tell that the caches are in sync with each other or not. By somewhat poor analogy, there's no way for me to check for the equivalent of a DNS SOA record to see which cache may be more up to date and to "do something" about that. -- Jeff From randy@psg.com Wed Aug 4 09:48:50 2010 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 D4B0828C0D0 for ; Wed, 4 Aug 2010 09:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 ZOtINCwb2tvb for ; Wed, 4 Aug 2010 09:48:50 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A351D3A6898 for ; Wed, 4 Aug 2010 09:48:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ogh9Z-000PN2-V9; Wed, 04 Aug 2010 16:49:18 +0000 Date: Wed, 04 Aug 2010 18:49:16 +0200 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20100804153322.GB25173@slice> References: <20100804153322.GB25173@slice> 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] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 16:48:51 -0000 > Could the authors comment on the expected behavior of a single router with a > pair of sessions to cache servers operated by the same provider which > implement the same RPKI policy? yes. do not do it. > The use-case I have in mind is that a given provider may have a number of > cache servers deployed within their network. A given router may wish to > have a session with two servers for redundancy purposes. do not do it > Given the current protocol, the best a router can do is know that it has all > of the records from a given cache server. There is no way to tell that > the caches are in sync with each other or not. you can safely assume that they are not randy From jhaas@slice.pfrc.org Wed Aug 4 09:55:21 2010 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 AAE4A28C0D8 for ; Wed, 4 Aug 2010 09:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.733 X-Spam-Level: X-Spam-Status: No, score=-101.733 tagged_above=-999 required=5 tests=[AWL=0.532, 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 MeERmVIIiSw8 for ; Wed, 4 Aug 2010 09:55:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 01B3F3A68B8 for ; Wed, 4 Aug 2010 09:55:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B39952251EB; Wed, 4 Aug 2010 16:55:50 +0000 (UTC) Date: Wed, 4 Aug 2010 16:55:50 +0000 From: Jeffrey Haas To: Randy Bush Message-ID: <20100804165550.GA27032@slice> References: <20100804153322.GB25173@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 16:55:21 -0000 On Wed, Aug 04, 2010 at 06:49:16PM +0200, Randy Bush wrote: > > The use-case I have in mind is that a given provider may have a number of > > cache servers deployed within their network. A given router may wish to > > have a session with two servers for redundancy purposes. > > do not do it It seems odd for you of all people, Randy, to want a feature that can so severely impact traffic to have a single point of failure. Thanks for clearing things up though. I'm interested in the opinion of the rest of the WG on this operational matter. -- Jeff From sra@hactrn.net Wed Aug 4 10:07:42 2010 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 7EBCB3A6880 for ; Wed, 4 Aug 2010 10:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.186 X-Spam-Level: X-Spam-Status: No, score=-100.186 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI3xm0pexAZc for ; Wed, 4 Aug 2010 10:07:41 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 0C5663A68B8 for ; Wed, 4 Aug 2010 10:07:41 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 7EF5228441 for ; Wed, 4 Aug 2010 17:08:08 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3662522829 for ; Wed, 4 Aug 2010 13:08:08 -0400 (EDT) Date: Wed, 04 Aug 2010 13:08:08 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20100804153322.GB25173@slice> References: <20100804153322.GB25173@slice> 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: <20100804170808.3662522829@thrintun.hactrn.net> Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 17:07:42 -0000 At Wed, 4 Aug 2010 15:33:22 +0000, Jeffrey Haas wrote: > > Could the authors comment on the expected behavior of a single router with a > pair of sessions to cache servers operated by the same provider which > implement the same RPKI policy? > > The use-case I have in mind is that a given provider may have a number of > cache servers deployed within their network. A given router may wish to > have a session with two servers for redundancy purposes. Yes, the protocol is designed to support that. > Given the current protocol, the best a router can do is know that it has all > of the records from a given cache server. There is no way to tell that > the caches are in sync with each other or not. If it really cares whether the caches are exactly in sync, it could compare the results, but I doubt that doing so would be particularly useful. This protocol is presenting a live view of a loosely consistent distributed database, there is no way to force two caches into lock step that does not involve fate sharing, which would defeat the point of using redundant caches. > By somewhat poor analogy, there's no way for me to check for the equivalent > of a DNS SOA record to see which cache may be more up to date and to "do > something" about that. There is no concept equivalent to a DNS zone in the RPKI system. Given that the state of each RPKI cache is a composite of the states of each of the however many objects it might be tracking (best guess for fully deployed system is tens or hundreds of thousands of objects, collected from an arbitrary number of publication points worldwide), the answer to your question is probably "mu", even before factoring in fat fingers problems such as clock or trust anchor skew. About the only useful thing i can see the router doing here is to compare the cache update times (as perceived by the router). If one cache is reporting frequent updates and the other is not, odds are that the first one is healthy and the second one is not, but even that's just guessing, the first might just have horrible intermittent connectivity to the outside or a whacked clock, so you might also want to check size of the respective databases. To a first approximation, a router using this protocol just has to trust the cache. There's nothing (other than CPU and storage hits) to prevent a router that doesn't trust caches from maintaining its own, but the point of this protocol is to get something we can deploy cheaply on current generation hardware. Tracking multiple caches in case one of them dies is probably wise; attempting to get clever about hopping from one to another in an attempt to be smarter than any of your caches is probably beyond the intended scope of this protocol. From sra@hactrn.net Wed Aug 4 10:22:14 2010 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 14DBF28C0D8 for ; Wed, 4 Aug 2010 10:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.393 X-Spam-Level: X-Spam-Status: No, score=-101.393 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8VLIufps7yY for ; Wed, 4 Aug 2010 10:22:13 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 06F5B28C0E8 for ; Wed, 4 Aug 2010 10:22:13 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 7A85928431 for ; Wed, 4 Aug 2010 17:22:42 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 34CEC22829 for ; Wed, 4 Aug 2010 13:22:42 -0400 (EDT) Date: Wed, 04 Aug 2010 13:22:42 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20100804170808.3662522829@thrintun.hactrn.net> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> 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: <20100804172242.34CEC22829@thrintun.hactrn.net> Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 17:22:14 -0000 To remove any confusion caused by the apparent contradiction between the answers that Randy and I gave: - It's ok to have connections open to more than one cache server at a time, but if you're going to do that, you have to buffer the results for each cache separately. - It's -not- ok to -use- the data from more than one cache server at a time, attempt to combine the data from multiple cache servers in any way, or otherwise get clever about comparing data from multiple cache servers. - The only point of allowing multiple connections is to allow fast transfer to a new cache if the cache one has been using dies. That is: we're trying to avoid the situation where you realize that the cache you're using has died, and it takes several minutes to get a full load from an alternate cache. - The main way of detecting that the cache you're using has died is the (required) periodic poll; if other mechanisms happen to give you a hint sooner, fine, but that's the real check. - This is all covered in the draft, albeit somewhat tersely. If you think it's unclear, please send text. From root@core3.amsl.com Wed Aug 4 10:30:49 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 053103A6A89; Wed, 4 Aug 2010 10:30:18 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100804173026.053103A6A89@core3.amsl.com> Date: Wed, 4 Aug 2010 10:30:13 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-pfx-validate-00.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: Wed, 04 Aug 2010 17:30:50 -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 : BGP Prefix Origin Validation Author(s) : P. Mohapatra, et al. Filename : draft-ietf-sidr-pfx-validate-00.txt Pages : 11 Date : 2010-07-28 A BGP route associates an address prefix with a set of autonomous systems (AS) that identify the interdomain path the prefix has traversed in the form of BGP announcements. This set is represented as the AS_PATH attribute in BGP and starts with the AS that originated the prefix. To help reduce well-known threats against BGP including prefix mis-announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-pfx-validate-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-04101922.I-D@ietf.org> --NextPart-- From jhaas@slice.pfrc.org Wed Aug 4 10:43:55 2010 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 3F38A3A67D3 for ; Wed, 4 Aug 2010 10:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.817 X-Spam-Level: X-Spam-Status: No, score=-100.817 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_20=-0.74, 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 180ZmLyHmA6g for ; Wed, 4 Aug 2010 10:43:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 5F1843A657C for ; Wed, 4 Aug 2010 10:43:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3A3FF224335; Wed, 4 Aug 2010 17:44:24 +0000 (UTC) Date: Wed, 4 Aug 2010 17:44:24 +0000 From: Jeffrey Haas To: Rob Austein Message-ID: <20100804174424.GA27912@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100804170808.3662522829@thrintun.hactrn.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 17:43:55 -0000 Rob, Thanks for a clearer answer than Randy's. On Wed, Aug 04, 2010 at 01:08:08PM -0400, Rob Austein wrote: > If it really cares whether the caches are exactly in sync, it could > compare the results, but I doubt that doing so would be particularly > useful. This protocol is presenting a live view of a loosely > consistent distributed database, there is no way to force two caches > into lock step that does not involve fate sharing, which would defeat > the point of using redundant caches. The issue is less a matter of being in lock-step between a pair of caches. My concern is that if a cache is out of step with the policy server that is used to populate that cache. In this particular case, the protocol will move along happily and you'll see updates from one server, but not the other. What I had in mind was a simple message from the cache server noting what its database version number was from the policy server and the last update time. This would permit a router to note when a cache has become radically desynchronized from its redundantly configured cache. > There is no concept equivalent to a DNS zone in the RPKI system. > > Given that the state of each RPKI cache is a composite of the states > of each of the however many objects it might be tracking (best guess > for fully deployed system is tens or hundreds of thousands of objects, > collected from an arbitrary number of publication points worldwide), > the answer to your question is probably "mu", even before factoring in > fat fingers problems such as clock or trust anchor skew. I think I see my confusion. I wouldn't have expected a provider to operate multiple pieces of infrastructure to gather RPKI objects and generate policy from them. Since consistency of policy is important, this scenario didn't occur to me. Given the assumption above of more than one RPKI object collector and policy generator, I can see how a domain-wide policy serial number would be problematic. Thanks for the clarification. > To a first approximation, a router using this protocol just has to > trust the cache. There's nothing (other than CPU and storage hits) to > prevent a router that doesn't trust caches from maintaining its own, > but the point of this protocol is to get something we can deploy > cheaply on current generation hardware. I agree that the protocol accomplishes this nicely. > Tracking multiple caches in > case one of them dies is probably wise; attempting to get clever about > hopping from one to another in an attempt to be smarter than any of > your caches is probably beyond the intended scope of this protocol. I'd say I'm still concerned about redudannt cache integrity and that the WG should spend a few cycles considering reasonable and inexpensive to implement solutions. As I pointed out to Randy, a single point of failure for such a stateful mechanism is problematic. Random example since I'm here: We learn 10/8 le 24 from cache servers A and B. The refcount is thus 2. A becomes desynchronized for some long period of time. B withdraws 10/8 le 24. The remaining refcount is 1 for as long as it stays desynchronized. Thus a previously authorized prefix which should be unauthorized remains in the system. Bounding the time that such a thing stays in the system would be my goal. -- Jeff From sra@hactrn.net Wed Aug 4 11:06:31 2010 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 AF7FA3A63EC for ; Wed, 4 Aug 2010 11:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI-KIdtTMSKx for ; Wed, 4 Aug 2010 11:06:27 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id D85A03A698F for ; Wed, 4 Aug 2010 11:06:25 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id BCD3A28441 for ; Wed, 4 Aug 2010 18:06:53 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 77B3B22829 for ; Wed, 4 Aug 2010 14:06:53 -0400 (EDT) Date: Wed, 04 Aug 2010 14:06:53 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20100804174424.GA27912@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> 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: <20100804180653.77B3B22829@thrintun.hactrn.net> Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 18:06:31 -0000 At Wed, 4 Aug 2010 17:44:24 +0000, Jeffrey Haas wrote: > > My concern is that if a cache is out of step with the policy server > that is used to populate that cache. This description makes no sense in the context of the current protocol and implementations. You've introduced an independent element between the RPKI and the rpki-router protocol server (your "policy server"), then postulated a failure of that element. How you handle failures in elements you introduce would be between you and your rabbi. :) From randy@psg.com Wed Aug 4 11:36:41 2010 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 2F1553A68B2 for ; Wed, 4 Aug 2010 11:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 8BJPVE6i177D for ; Wed, 4 Aug 2010 11:36:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 86A8D3A67DB for ; Wed, 4 Aug 2010 11:36:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ogipw-000Pif-6Y; Wed, 04 Aug 2010 18:37:08 +0000 Date: Wed, 04 Aug 2010 20:37:07 +0200 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20100804174424.GA27912@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> 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] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 18:36:41 -0000 > The issue is less a matter of being in lock-step between a pair of > caches. My concern is that if a cache is out of step with the policy > server that is used to populate that cache. i have no idea what a policy server is. > What I had in mind was a simple message from the cache server noting > what its database version number was from the policy server and the > last update time. This would permit a router to note when a cache has > become radically desynchronized from its redundantly configured cache. there are no redundantly configured caches. there are no database version numbers. read the draft. > I think I see my confusion. I wouldn't have expected a provider to > operate multiple pieces of infrastructure to gather RPKI objects and > generate policy from them. Since consistency of policy is important, > this scenario didn't occur to me. and a globaly consistent view of the dns is important. it just happens not to exist. and global bgp never really converges. from section 5 As caches can not be rigorously synchronous, a client which changes servers can not combine data from different parent caches. Therefore, when a lower preference cache becomes available, if resources allow, it would be prudent for the client to start a new buffer for that cache's data, and only switch to those data when that buffer is fully up to date. i could add a lot of words, but i don't think it would make things much clearer. i am thinking of including the roll slide from the maastricht preso in the next version. but some folk have pointed out that there are other recipies that are as good. > Given the assumption above of more than one RPKI object collector and > policy generator, I can see how a domain-wide policy serial number > would be problematic. how about the assumption of multiple object collectors and no policy generator(s)? > I'd say I'm still concerned about redudannt cache integrity and that > the WG should spend a few cycles considering reasonable and > inexpensive to implement solutions. when you actually have a proposal, do make it. > As I pointed out to Randy, a single point of failure for such a > stateful mechanism is problematic. what single point of failure? and please refer to the draft and do not invent components which are not there. randy From randy@psg.com Wed Aug 4 11:41:43 2010 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 29AF63A67E2 for ; Wed, 4 Aug 2010 11:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 H+oh17k-rN1x for ; Wed, 4 Aug 2010 11:41:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id E06AD3A657C for ; Wed, 4 Aug 2010 11:41:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ogiuo-000Pk7-Sh; Wed, 04 Aug 2010 18:42:11 +0000 Date: Wed, 04 Aug 2010 20:42:08 +0200 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20100804165550.GA27032@slice> References: <20100804153322.GB25173@slice> <20100804165550.GA27032@slice> 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] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 18:41:43 -0000 >>> The use-case I have in mind is that a given provider may have a number of >>> cache servers deployed within their network. A given router may wish to >>> have a session with two servers for redundancy purposes. >> >> do not do it > > It seems odd for you of all people, Randy, to want a feature that can so > severely impact traffic to have a single point of failure. sans ad homina, what is the spof? i suspect you have not read the, admittedly and intentionally terse, draft carefully. randy From jhaas@slice.pfrc.org Wed Aug 4 12:01:57 2010 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 11B433A680B for ; Wed, 4 Aug 2010 12:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.992 X-Spam-Level: X-Spam-Status: No, score=-100.992 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeSONwUFzEOd for ; Wed, 4 Aug 2010 12:01:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 2761E3A6993 for ; Wed, 4 Aug 2010 12:01:40 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D4866224343; Wed, 4 Aug 2010 19:02:09 +0000 (UTC) Date: Wed, 4 Aug 2010 19:02:09 +0000 From: Jeffrey Haas To: Rob Austein Message-ID: <20100804190209.GB27912@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> <20100804180653.77B3B22829@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100804180653.77B3B22829@thrintun.hactrn.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 19:01:57 -0000 On Wed, Aug 04, 2010 at 02:06:53PM -0400, Rob Austein wrote: > At Wed, 4 Aug 2010 17:44:24 +0000, Jeffrey Haas wrote: > > > > My concern is that if a cache is out of step with the policy server > > that is used to populate that cache. > > This description makes no sense in the context of the current protocol > and implementations. You've introduced an independent element between > the RPKI and the rpki-router protocol server (your "policy server"), > then postulated a failure of that element. How you handle failures in > elements you introduce would be between you and your rabbi. :) Let me attempt to correct my incorrect verbiage. It's been a while since I've read the -arch document. -arch notes that a provider must maintain a Local Cache. The Local Cache may contain configuration - policy - that directs things like which TAs to use. After processing the RPKI objects, the output is effectively a database of prefixes (and max-lengths) and their origin ASes. A provider may wish to override validated RPKI data for their own purposes. While not explicitly a SIDR-driven requirement, this was discussed multiple times as a requirement during the original RPSEC work. The resulting output (override or no), is a set of AS:prefix/maxlen tuples that reflects the provider's routing policy with regard to origin validation. This policy must now be distributed to routers for implementation. The mechanism for distributing the policy is currently draft-ymbk-rpki-rtr-protocol. Implementation/Deployment models: 1. The Local Cache with resulting routing origin policy and the rpki-router protocol server are in the same box. In this model, the provider will likely have to deploy more than a single instance of this model throughout their network. This will result in each box hitting the RPKI repositories in order to keep their state fresh. Presuming the lack of a mechanism to keep each box in lock-step with their state, this provides a scenario where these servers may become out of synch with each other. This may yield inconsistent routing origin policy within a given network. 2. The Local Cache with resulting routing origin policy is implemented within one box. The rpki-router protocol servers are located in multiple boxes. In this model, the single Local Cache minimizes the impact on the global RPKI repository infrastructure. A mechanism is required to distribute the resulting origin routing policy to the rpki-router servers (let's call it scp for simplicity's sake). The only way for this infrastructure to provide inconsistent routing origin policy within the network would be for the Local Cache to be topologically isolated from the rpki-router servers. This is a detectable condition at the Local Cache presuming a push model where it is noted that the push fails. In both models there is a possibility that the rpki-router server session is up but the server session is out of sync with the RPKI within a given network. This yields inconsistent policy which is usually considered a Bad Thing. If you don't have this perspective, you must be talking to different providers than I am. I believe it is possible to minimally update the rpki-router protocol to allow routers to detect policy skew. -- Jeff From jhaas@slice.pfrc.org Wed Aug 4 12:27:37 2010 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 2FBD23A68B2 for ; Wed, 4 Aug 2010 12:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.802 X-Spam-Level: X-Spam-Status: No, score=-100.802 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_20=-0.74, 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 ArMRYnItTJso for ; Wed, 4 Aug 2010 12:27:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 66F833A67DB for ; Wed, 4 Aug 2010 12:27:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5597D22433F; Wed, 4 Aug 2010 19:28:06 +0000 (UTC) Date: Wed, 4 Aug 2010 19:28:06 +0000 From: Jeffrey Haas To: sidr@ietf.org Message-ID: <20100804192806.GC27912@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> <20100804180653.77B3B22829@thrintun.hactrn.net> <20100804190209.GB27912@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100804190209.GB27912@slice> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 19:27:37 -0000 To amend my last post: On Wed, Aug 04, 2010 at 07:02:09PM +0000, Jeffrey Haas wrote: > Implementation/Deployment models: > 1. The Local Cache with resulting routing origin policy and the rpki-router > protocol server are in the same box. > > In this model, the provider will likely have to deploy more than a single > instance of this model throughout their network. This will result in each > box hitting the RPKI repositories in order to keep their state fresh. > Presuming the lack of a mechanism to keep each box in lock-step with their > state, this provides a scenario where these servers may become out of synch > with each other. This may yield inconsistent routing origin policy > within a given network. The draft also covers a Large End Sites which have a hierarchy of servers. Scenario 1 still roughly covers this hierarchy where intra-provider cache servers may not be consistent. -- Jeff From sra@hactrn.net Wed Aug 4 12:40:51 2010 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 7FE263A6985 for ; Wed, 4 Aug 2010 12:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.198 X-Spam-Level: X-Spam-Status: No, score=-102.198 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhrZFk2aFZcK for ; Wed, 4 Aug 2010 12:40:50 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id B2F7C3A6960 for ; Wed, 4 Aug 2010 12:40:49 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id BDEF728431 for ; Wed, 4 Aug 2010 19:41:17 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 766AF22829 for ; Wed, 4 Aug 2010 15:41:17 -0400 (EDT) Date: Wed, 04 Aug 2010 15:41:17 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20100804190209.GB27912@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> <20100804180653.77B3B22829@thrintun.hactrn.net> <20100804190209.GB27912@slice> 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: <20100804194117.766AF22829@thrintun.hactrn.net> Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 19:40:51 -0000 Last message for a bit, as I do have other things I need to do today. At Wed, 4 Aug 2010 19:02:09 +0000, Jeffrey Haas wrote: > > Let me attempt to correct my incorrect verbiage. It's been a while since > I've read the -arch document. > > -arch notes that a provider must maintain a Local Cache. Yes. > The Local Cache may contain configuration - policy - that directs things > like which TAs to use. After processing the RPKI objects, the output is > effectively a database of prefixes (and max-lengths) and their origin ASes. And other data which you appear to be ignoring, but let that pass for now. > A provider may wish to override validated RPKI data for their own purposes. > While not explicitly a SIDR-driven requirement, this was discussed multiple > times as a requirement during the original RPSEC work. What RPSEC did or did not say is not my problem, but I agree that an operator has policy settings somewhere. At present, they're mostly in the router itself, thanks to Doctor Knob; the only policy setting in the RPKI part of the picture at the moment is choice of trust anchor, which is a basic configuration issue for the validator and something we almost certainly do not want to extrude into the rpki-rtr protocol. > The resulting output (override or no), is a set of AS:prefix/maxlen tuples > that reflects the provider's routing policy with regard to origin > validation. You're jumping to the conclusion that policy is applied before distribution. > This policy must now be distributed to routers for implementation. The > mechanism for distributing the policy is currently > draft-ymbk-rpki-rtr-protocol. No. That protocol is specified as distributing distilled RPKI data (or distilled IRR data, if you're trusting enough to use that). Show me where that draft says -anything- about distributing policy. The word never even appears in the draft. The rest of your message is a detailed derivation of how you get into trouble by attempting to feed policy down a protocol pipe that was not designed to carry it. I will note that, of your two options, ignoring your injection of policy into the protocol, the first one (co-location of RPKi validator with rpki-rtr server) is the one we envisioned, although one can imagine more complex topologies where validators fetch from pre-aggregated caches generated by other validators, to reduce external load and promote a weak form of coherence. Note that in a complex topology the object timestamps will tend to do what you want automatically, given that we're using rsync as the RPKi data gathering tool. Also note that all of the fancy topology stuff would happen in front of RPKI validation, by the time one has gotten past that it's just the rpki-rtr protocol feeding results to the routers. Your second option, on the other hand, creates a nasty single point of failure. Insert Randy's standard comment about encouraging all of my competitors to do that. But I really think your problem here is confusion of the rpki-rtr protocol with a policy distribution service. It's not intended to be that, thus your call for a scheme to detect skew in something it was never intended to carry looks out of scope to me. From jhaas@slice.pfrc.org Wed Aug 4 12:49:01 2010 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 418073A67D3 for ; Wed, 4 Aug 2010 12:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.722 X-Spam-Level: X-Spam-Status: No, score=-101.722 tagged_above=-999 required=5 tests=[AWL=0.543, 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 rM9Tn+uOspTx for ; Wed, 4 Aug 2010 12:49:00 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 50AA03A6915 for ; Wed, 4 Aug 2010 12:49:00 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 42E76224344; Wed, 4 Aug 2010 19:49:30 +0000 (UTC) Date: Wed, 4 Aug 2010 19:49:30 +0000 From: Jeffrey Haas To: Randy Bush Message-ID: <20100804194930.GD27912@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 19:49:01 -0000 On Wed, Aug 04, 2010 at 08:37:07PM +0200, Randy Bush wrote: > there are no redundantly configured caches. : 7. Router-Cache Set-Up : [...] : A router may be configured to peer with a selection of caches > there are no database version numbers. That was my proposal and not my assertion that your protocol included this. > read the draft. Aside from my sloppy verbiage, you're mistaken if you think I haven't. It's why I'm asking questions. > As caches can not be rigorously synchronous, a client which changes > servers can not combine data from different parent caches. > Therefore, when a lower preference cache becomes available, if > resources allow, it would be prudent for the client to start a new > buffer for that cache's data, and only switch to those data when that > buffer is fully up to date. And the crux of my question is, why can't they be synchronous at least within a given provider domain? Or at least synchronous enough? > how about the assumption of multiple object collectors and no policy > generator(s)? The default policy is your choice of trust anchors. > > I'd say I'm still concerned about redudannt cache integrity and that > > the WG should spend a few cycles considering reasonable and > > inexpensive to implement solutions. > > when you actually have a proposal, do make it. What I had said in a prior e-mail was: > What I had in mind was a simple message from the cache server noting what > its database version number was from the policy server and the last update > time. This would permit a router to note when a cache has become radically > desynchronized from its redundantly configured cache. At this point, the deployment model that appears to be documented (Section 8) seems to presume that it's okay to have inconsistent RPKI policy within a provider. If everyone is cool with that, we're done. If not, then we have more work to do, even if it's not a simple database version number. > > As I pointed out to Randy, a single point of failure for such a > > stateful mechanism is problematic. > > what single point of failure? and please refer to the draft and do not > invent components which are not there. This was in response to your original comment: On Wed, Aug 04, 2010 at 06:49:16PM +0200, Randy Bush wrote: > > The use-case I have in mind is that a given provider may have a number > > of > > cache servers deployed within their network. A given router may wish to > > have a session with two servers for redundancy purposes. > > do not do it If you can't have a session with more than one server, you have a single point of failure. > randy From randy@psg.com Wed Aug 4 12:56:01 2010 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 AD3283A6965 for ; Wed, 4 Aug 2010 12:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 pZo8KlCPodHF for ; Wed, 4 Aug 2010 12:56:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A52DC3A6960 for ; Wed, 4 Aug 2010 12:56:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ogk4j-00002J-Eh; Wed, 04 Aug 2010 19:56:29 +0000 Date: Wed, 04 Aug 2010 21:56:28 +0200 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20100804194930.GD27912@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> <20100804194930.GD27912@slice> 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] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 19:56:01 -0000 > At this point, the deployment model that appears to be documented > (Section 8) seems to presume that it's okay to have inconsistent RPKI > policy within a provider. If everyone is cool with that, we're done. there is no rpki policy in this document. hence such policies can not be inconsistent. Abstract In order to formally validate the origin ASes 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. i encourage you to describe and document a protocol which maintains synchronized and skew-free trusted caches. sorry, i did not know how, and did not think it was actually needed or appropriate in this context. randy From jhaas@slice.pfrc.org Wed Aug 4 13:20:58 2010 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 5E1413A6960 for ; Wed, 4 Aug 2010 13:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.434 X-Spam-Level: X-Spam-Status: No, score=-101.434 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_53=0.6, 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 KkfKb0GF+1+Z for ; Wed, 4 Aug 2010 13:20:57 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 55E563A6866 for ; Wed, 4 Aug 2010 13:20:57 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4D86922434D; Wed, 4 Aug 2010 20:21:27 +0000 (UTC) Date: Wed, 4 Aug 2010 20:21:27 +0000 From: Jeffrey Haas To: Rob Austein Message-ID: <20100804202127.GE27912@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> <20100804180653.77B3B22829@thrintun.hactrn.net> <20100804190209.GB27912@slice> <20100804194117.766AF22829@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100804194117.766AF22829@thrintun.hactrn.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 20:20:58 -0000 On Wed, Aug 04, 2010 at 03:41:17PM -0400, Rob Austein wrote: > > A provider may wish to override validated RPKI data for their own purposes. > > While not explicitly a SIDR-driven requirement, this was discussed multiple > > times as a requirement during the original RPSEC work. > > What RPSEC did or did not say is not my problem, but I agree that an > operator has policy settings somewhere. At present, they're mostly in > the router itself, thanks to Doctor Knob; the only policy setting in > the RPKI part of the picture at the moment is choice of trust anchor, > which is a basic configuration issue for the validator and something > we almost certainly do not want to extrude into the rpki-rtr protocol. I think you have chosen to take the word policy and apply it in the route filtering sense rather than my intended RPKI sense. Please insert whatever word you want to use that directs my use of which objects from the RPKI I choose to be permitted for validation purposes. The simplest example of this would be "I choose not to trust Foo-NIC as a trust anchor". Another example would be "I choose to ignore AS64512's objects". My intention was never "drop 10/8 le 24 from BGP" in the style of RPSL. > I will note that, of your two options, ignoring your injection of > policy into the protocol, the first one (co-location of RPKi validator > with rpki-rtr server) is the one we envisioned, although one can > imagine more complex topologies where validators fetch from > pre-aggregated caches generated by other validators, to reduce > external load and promote a weak form of coherence. Note that in a > complex topology the object timestamps will tend to do what you want > automatically, given that we're using rsync as the RPKi data gathering > tool. Also note that all of the fancy topology stuff would happen in > front of RPKI validation, by the time one has gotten past that it's > just the rpki-rtr protocol feeding results to the routers. Let's stick with this example since it's sufficient for my point as long as we're talking about a set of caches in a single domain/AS/administrative region/etc. and have consistent configuration. Ignoring rpki-rtr, there should be a mechanism to determine whether all of the local caches within the domain are consistent with each other. Pathologically, this is each cache rsync'ing with every other cache and finding no changes. More realistically, it'd be agreement that all objects of a certain age are present on all caches. Passing that age into the rpki-rtr protocol is sufficient to establish a measure of confidence in the consistency of caches in the same domain for differing sessions. -- Jeff From randy@psg.com Wed Aug 4 13:29:18 2010 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 7A4373A6A13 for ; Wed, 4 Aug 2010 13:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 Lx1+dn+Hq34c for ; Wed, 4 Aug 2010 13:29:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 834833A6A12 for ; Wed, 4 Aug 2010 13:29:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ogkat-00008d-08; Wed, 04 Aug 2010 20:29:43 +0000 Date: Wed, 04 Aug 2010 22:29:40 +0200 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20100804202127.GE27912@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> <20100804180653.77B3B22829@thrintun.hactrn.net> <20100804190209.GB27912@slice> <20100804194117.766AF22829@thrintun.hactrn.net> <20100804202127.GE27912@slice> 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: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 20:29:18 -0000 > I think you have chosen to take the word policy and apply it in the > route filtering sense rather than my intended RPKI sense. Please insert > whatever word you want to use that directs my use of which objects from the > RPKI I choose to be permitted for validation purposes. The simplest example > of this would be "I choose not to trust Foo-NIC as a trust anchor". Another > example would be "I choose to ignore AS64512's objects". My intention was > never "drop 10/8 le 24 from BGP" in the style of RPSL. i need to sleep, long day tomorrow, but one more try. this document is not about how, why, and under what policies you get whatever you get into whatever cache(s) you trust. please read the above sentence a few times slowly. this document is utterly independent of what trust anchors, chicken entrails, or borg mind controls caused whatever data to be put in the cache(s). this document is about how we get those data UNEDITED AND WITH NO POLICY APPLIED from one or more of these caches to a router. randy From jhaas@slice.pfrc.org Wed Aug 4 13:33:48 2010 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 EC19D3A67A4 for ; Wed, 4 Aug 2010 13:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.739 X-Spam-Level: X-Spam-Status: No, score=-101.739 tagged_above=-999 required=5 tests=[AWL=0.526, 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 cYLrA+dEWWz8 for ; Wed, 4 Aug 2010 13:33:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id DE9873A6A2B for ; Wed, 4 Aug 2010 13:33:46 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DB4EE224349; Wed, 4 Aug 2010 20:34:16 +0000 (UTC) Date: Wed, 4 Aug 2010 20:34:16 +0000 From: Jeffrey Haas To: Randy Bush Message-ID: <20100804203416.GC29697@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> <20100804180653.77B3B22829@thrintun.hactrn.net> <20100804190209.GB27912@slice> <20100804194117.766AF22829@thrintun.hactrn.net> <20100804202127.GE27912@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 04 Aug 2010 20:33:48 -0000 On Wed, Aug 04, 2010 at 10:29:40PM +0200, Randy Bush wrote: > this document is not about how, why, and under what policies you get > whatever you get into whatever cache(s) you trust. Ignore policy. Answer the second paragraph in the context of *unedited cache consistency* from the same mail you just quoted and we're done. -- Jeff From randy@psg.com Thu Aug 5 03:27:45 2010 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 97BC73A69F6 for ; Thu, 5 Aug 2010 03:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 mbmVAsybhGxp for ; Thu, 5 Aug 2010 03:27:44 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A73F83A686D for ; Thu, 5 Aug 2010 03:27:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OgxgL-0003Fo-OU; Thu, 05 Aug 2010 10:28:14 +0000 Date: Thu, 05 Aug 2010 12:28:12 +0200 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20100804203416.GC29697@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> <20100804180653.77B3B22829@thrintun.hactrn.net> <20100804190209.GB27912@slice> <20100804194117.766AF22829@thrintun.hactrn.net> <20100804202127.GE27912@slice> <20100804203416.GC29697@slice> 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] Comments on draft-ymbk-rpki-rtr-protocol 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, 05 Aug 2010 10:27:45 -0000 > Answer the second paragraph in the context of *unedited cache > consistency* givem the rpki operational structure, it would be deliciously wonderful if you could describe how multiple gathered caches thereof can be consistent. anxiously awaiting your design. randy From bmanning@karoshi.com Thu Aug 5 03:50:12 2010 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 B23D63A6AF6 for ; Thu, 5 Aug 2010 03:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 NLZsw6dkN4b9 for ; Thu, 5 Aug 2010 03:50:11 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id CF7353A6AF0 for ; Thu, 5 Aug 2010 03:50:11 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o75Aogjq028990; Thu, 5 Aug 2010 10:50:42 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o75AogNE028989; Thu, 5 Aug 2010 10:50:42 GMT Date: Thu, 5 Aug 2010 10:50:42 +0000 From: bmanning@vacation.karoshi.com To: Randy Bush Message-ID: <20100805105042.GB28355@vacation.karoshi.com.> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> <20100804180653.77B3B22829@thrintun.hactrn.net> <20100804190209.GB27912@slice> <20100804194117.766AF22829@thrintun.hactrn.net> <20100804202127.GE27912@slice> <20100804203416.GC29697@slice> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 05 Aug 2010 10:50:12 -0000 On Thu, Aug 05, 2010 at 12:28:12PM +0200, Randy Bush wrote: > > Answer the second paragraph in the context of *unedited cache > > consistency* > > givem the rpki operational structure, it would be deliciously wonderful > if you could describe how multiple gathered caches thereof can be > consistent. consistent with what exactly? i would hope/expect that the caches w/in a given AS should be consistent within the AS but have no illusions about external consistancy with anyone else (other AS or RIR) --bill > > anxiously awaiting your design. > > randy From randy@psg.com Thu Aug 5 03:53:24 2010 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 D6C263A6A72 for ; Thu, 5 Aug 2010 03:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 obnWWFTTv5PP for ; Thu, 5 Aug 2010 03:53:24 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id CF66F3A691A for ; Thu, 5 Aug 2010 03:53:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ogy59-0003MA-B0; Thu, 05 Aug 2010 10:53:51 +0000 Date: Thu, 05 Aug 2010 12:53:49 +0200 Message-ID: From: Randy Bush To: bmanning@vacation.karoshi.com In-Reply-To: <20100805105042.GB28355@vacation.karoshi.com.> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> <20100804180653.77B3B22829@thrintun.hactrn.net> <20100804190209.GB27912@slice> <20100804194117.766AF22829@thrintun.hactrn.net> <20100804202127.GE27912@slice> <20100804203416.GC29697@slice> 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] Comments on draft-ymbk-rpki-rtr-protocol 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, 05 Aug 2010 10:53:24 -0000 >> givem the rpki operational structure, it would be deliciously wonderful >> if you could describe how multiple gathered caches thereof can be >> consistent. > consistent with what exactly? as no other entities were mentioned, it would be safe to assume eachother. > i would hope/expect that the caches w/in a given AS should be > consistent within the AS but have no illusions about external > consistancy with anyone else (other AS or RIR) while you are hoping and expecting, send design for a scheme to assure this. until then, i have real work to do. randy From jhaas@slice.pfrc.org Thu Aug 5 04:39:32 2010 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 A5FC03A6A85 for ; Thu, 5 Aug 2010 04:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.751 X-Spam-Level: X-Spam-Status: No, score=-101.751 tagged_above=-999 required=5 tests=[AWL=0.514, 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 Qei43S9N9mAn for ; Thu, 5 Aug 2010 04:39:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id C47343A686B for ; Thu, 5 Aug 2010 04:39:31 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9D62722433D; Thu, 5 Aug 2010 11:40:01 +0000 (UTC) Date: Thu, 5 Aug 2010 11:40:01 +0000 From: Jeffrey Haas To: bmanning@vacation.karoshi.com Message-ID: <20100805114000.GA14612@slice> References: <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> <20100804180653.77B3B22829@thrintun.hactrn.net> <20100804190209.GB27912@slice> <20100804194117.766AF22829@thrintun.hactrn.net> <20100804202127.GE27912@slice> <20100804203416.GC29697@slice> <20100805105042.GB28355@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100805105042.GB28355@vacation.karoshi.com.> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 05 Aug 2010 11:39:32 -0000 Bill, On Thu, Aug 05, 2010 at 10:50:42AM +0000, bmanning@vacation.karoshi.com wrote: > On Thu, Aug 05, 2010 at 12:28:12PM +0200, Randy Bush wrote: > > > Answer the second paragraph in the context of *unedited cache > > > consistency* > > > > givem the rpki operational structure, it would be deliciously wonderful > > if you could describe how multiple gathered caches thereof can be > > consistent. > > consistent with what exactly? > i would hope/expect that the caches w/in a given > AS should be consistent within the AS but have no > illusions about external consistancy with anyone > else (other AS or RIR) The model described is likely to lead to inconsistent route origin policy for eBGP speakers within a given AS for short periods of time. How short, and whether the behavior covered by a given ROA will converge to consistency within the AS will depend on the deployment model. -- Jeff From kent@bbn.com Thu Aug 5 07:48:38 2010 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 5490E3A6814 for ; Thu, 5 Aug 2010 07:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 OW0ru9BrWobm for ; Thu, 5 Aug 2010 07:48:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 1BEFF3A6B0F for ; Thu, 5 Aug 2010 07:48:36 -0700 (PDT) Received: from dhcp89-089-072.bbn.com ([128.89.89.72]:49256) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Oh1kn-0002zU-Qb; Thu, 05 Aug 2010 10:49:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100804190209.GB27912@slice> References: <20100804153322.GB25173@slice> <20100804170808.3662522829@thrintun.hactrn.net> <20100804174424.GA27912@slice> <20100804180653.77B3B22829@thrintun.hactrn.net> <20100804190209.GB27912@slice> Date: Thu, 5 Aug 2010 10:23:29 -0400 To: Jeffrey Haas From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-ymbk-rpki-rtr-protocol 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, 05 Aug 2010 14:48:38 -0000 >... > >A provider may wish to override validated RPKI data for their own purposes. >While not explicitly a SIDR-driven requirement, this was discussed multiple >times as a requirement during the original RPSEC work. A specific proposal for how to locally override the RPKI structure as retrieved form the repository system is contained in a document being considered as a SIDR WG item: http://tools.ietf.org/html/draft-reynolds-rpki-ltamgmt-00 > >The resulting output (override or no), is a set of AS:prefix/maxlen tuples >that reflects the provider's routing policy with regard to origin >validation. In the case of the doc cited above, it is not in that form. > >This policy must now be distributed to routers for implementation. The >mechanism for distributing the policy is currently >draft-ymbk-rpki-rtr-protocol. I think the ymbk protocol distributes the results of validating the RPKI data, with whatever policy has been applied to that validation process. Steve From pmohapat@cisco.com Sun Aug 8 14:02:02 2010 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 32E9C3A6894 for ; Sun, 8 Aug 2010 14:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 p0MO-Wmpy37r for ; Sun, 8 Aug 2010 14:01:59 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7C5613A680A for ; Sun, 8 Aug 2010 14:01:59 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGW4XkyrRN+K/2dsb2JhbACgRHGmTpomhToEhCaFFQ X-IronPort-AV: E=Sophos;i="4.55,338,1278288000"; d="scan'208";a="237401663" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 08 Aug 2010 21:02:32 +0000 Received: from sjc-vpn2-15.cisco.com (sjc-vpn2-15.cisco.com [10.21.112.15]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o78L2W2s029558; Sun, 8 Aug 2010 21:02:33 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: <20100804152443.GA25173@slice> Date: Sun, 8 Aug 2010 14:03:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100804152443.GA25173@slice> To: Jeffrey Haas X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-pmohapat-sidr-origin-validation-signaling 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, 08 Aug 2010 21:02:02 -0000 Hi Jeff, [Sorry about the delayed response] > In addition to the energetic discussion about the terminology for the = three > states of the community, I'd also like to suggest that the origin of = the > validation may be relevant. The cache protocol gives a data source = for the > validation and that source probably should be represented within this > community. This also argues that it may be reasonable to have = multiple > instances of this community - or that the representation of the data = source > should be a bit-vector. >=20 > I also wonder if "color" would need to go into a community such as = this one. > Since the current purpose of "color" is unclear, it's hard to know one = way > or the other. >=20 > The above has impact on the suggested changes to the BGP decision = process. > For example, an operator may prefer that RPKI validation have = precedence > over IRR validation. Similarly, "color" may impact it. The original thought process was that all the above you have listed are = local policy matter. E.g. the data source (RPKI or IRR) would be taken = as a local policy hint to prefer one vs. the other... Same with color = etc. Ultimately, it's only the path state that gets disseminated in IBGP = and the corresponding decision process change is defined in the draft. = But I see where you are going: if border router A fetches the origin = validation database from RPKI and another border router B fetches the = origin validation database from IRR, the third router receiving IBGP = updates may want to know the source to be able to make a better = decision. However this use case is extremely rare; do we really want to = go there? - Pradosh= From randy@psg.com Sun Aug 8 17:20:10 2010 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 461D43A69D7 for ; Sun, 8 Aug 2010 17:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 UWtRMs3VbbMO for ; Sun, 8 Aug 2010 17:20:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 19BDB3A69B3 for ; Sun, 8 Aug 2010 17:20:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OiG6Z-000MmK-4Z; Mon, 09 Aug 2010 00:20:39 +0000 Date: Sun, 08 Aug 2010 17:20:39 -0700 Message-ID: From: Randy Bush To: Pradosh Mohapatra In-Reply-To: References: <20100804152443.GA25173@slice> 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] Comments on draft-pmohapat-sidr-origin-validation-signaling 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, 09 Aug 2010 00:20:10 -0000 > if border router A fetches the origin validation database from RPKI > and another border router B fetches the origin validation database > from IRR, the third router receiving IBGP updates may want to know the > source to be able to make a better decision. However this use case is > extremely rare; do we really want to go there? no, let us not boil the ocean. the question is not how complex all this can be made, but rather how simple. randy From root@core3.amsl.com Wed Aug 11 06:45:03 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4307A3A689B; Wed, 11 Aug 2010 06:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100811134503.4307A3A689B@core3.amsl.com> Date: Wed, 11 Aug 2010 06:45:03 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-00.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: Wed, 11 Aug 2010 13: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 : The RPKI/Router Protocol Author(s) : R. Bush, R. Austein Filename : draft-ietf-sidr-rpki-rtr-00.txt Pages : 20 Date : 2010-08-11 In order to formally validate the origin ASes 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-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-rtr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-11063849.I-D@ietf.org> --NextPart-- From kotikalapudi.sriram@nist.gov Wed Aug 11 14:42:46 2010 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 6872C28C0F6 for ; Wed, 11 Aug 2010 14:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=0.318, 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 L36WYOCp8iWX for ; Wed, 11 Aug 2010 14:42:45 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 3F78D28C0F4 for ; Wed, 11 Aug 2010 14:42:45 -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 o7BLh3KI010650; Wed, 11 Aug 2010 17:43:03 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 11 Aug 2010 17:43:03 -0400 From: "Sriram, Kotikalapudi" To: Pradosh Mohapatra , Jeffrey Haas Date: Wed, 11 Aug 2010 17:42:40 -0400 Thread-Topic: [sidr] Comment about aggregators and AS_SETs Thread-Index: AcsyCtX+aJY3VpC4R0q6LIX5yaBicgHjhQuw Message-ID: References: <20100729135023.GD19401@slice> <071667FC-D672-4F81-BB2C-704C33CF709A@cisco.com> In-Reply-To: <071667FC-D672-4F81-BB2C-704C33CF709A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] Comment about aggregators and AS_SETs 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, 11 Aug 2010 21:42:46 -0000 Sorry for the delay in responding. Please see answers inline below. Sriram > -----Original Message----- > From: Pradosh Mohapatra [mailto:pmohapat@cisco.com] > Sent: Monday, August 02, 2010 2:21 AM > To: Jeffrey Haas > Cc: Sriram, Kotikalapudi; sidr@ietf.org > Subject: Re: [sidr] Comment about aggregators and AS_SETs > > I support Jeff's proposal for matching the "first AS after AS_SET" with the > [AS4_]AGGREGATOR attribute. If I understand correctly, the suggestion is to > follow the below algorithm for deriving origin_as: > > 1. origin_as = rightmost AS in the final AS_SEQUENCE of the AS_PATH attribute > 2. If the UPDATE carries [AS4_]AGGREGATOR and AS_SET attributes > if (first AS after AS_SET == AS encoded in [AS4_]AGGREGATOR), then > origin_as = first AS after AS_SET > else > origin_as = NONE > > Sriram, a quick question on your enumeration tree: the right hand side in the tree > starts with "No AS_SET", but later you have nodes that say "Matches the first AS > after AS_SET"... What does that mean? It was a typo. I meant "Matches the origin AS (i.e., the AGGREGATOR ASN and the right most AS of the AS_SEQUENCE match). Please see the corrected updated slides: http://www.antd.nist.gov/~ksriram/AS_SET_Aggregator_Stats.pdf >Also, IMO, the attack vector you mention > in the slides are more related to path validation than origin validation. I think the attack vector is possible for path validation as well as origin validation. But if you require, in the algorithm, that the first AS after AS_SET == AS encoded in AGGREGATOR and only then take that AS to be origin (Jeff Haas's modification to what I suggested), then the attack vector goes away. The attack vector is possible if we take the AGGREGATOR ASN to be origin (for origin validation) without paying attention to the first AS after AS_SET. Sriram > > - Pradosh From root@core3.amsl.com Sat Aug 14 20:15:02 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9B2303A69A5; Sat, 14 Aug 2010 20:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100815031501.9B2303A69A5@core3.amsl.com> Date: Sat, 14 Aug 2010 20:15:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-01.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: Sun, 15 Aug 2010 03:15: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-01.txt Pages : 20 Date : 2010-08-14 In order to formally validate the origin ASes 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-01.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-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-14201158.I-D@ietf.org> --NextPart-- From robertl@apnic.net Sun Aug 15 21:01:55 2010 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 449683A6947 for ; Sun, 15 Aug 2010 21:01:55 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icF31dG4Wzh5 for ; Sun, 15 Aug 2010 21:01:54 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 70D0D3A67D3 for ; Sun, 15 Aug 2010 21:01:53 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:21f:5bff:fef1:8eb9] (unknown [IPv6:2001:dc0:a000:4:21f:5bff:fef1:8eb9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 850A8D58C4; Mon, 16 Aug 2010 14:02:27 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Robert Loomans In-Reply-To: <4C4452D8.7080605@ripe.net> Date: Mon, 16 Aug 2010 14:02:27 +1000 Content-Transfer-Encoding: 7bit Message-Id: References: <4C3D7DD1.3080701@ripe.net> <94AFADC2-BFAC-4DB6-8155-CE4E937C30A5@apnic.net> <4C4452D8.7080605@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.1081) Cc: "sidr@ietf.org" Subject: Re: [sidr] some questions / comments on provisioning (up/down) 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, 16 Aug 2010 04:01:55 -0000 On 19/07/2010, at 23:27, Tim Bruijnzeels wrote: > I proposed the dedicated code because I figured we could bounce this > back when we see the same IP hammering us, without having to inspect the > actual request (which requires validating the CMS etc). However now that > I think about it a bit more, this would still require that we generate a > CMS for the response... Indeed. > So to conclude: I think I would prefer an http status return in this > case to minimise server processing power. Maybe something similar to > validation failure in paragraph 3.2: HTTP 400 Bad Data There is an existing HTTP code for this: 503 Service Unavailable. Rob -- Robert Loomans email: robertl@apnic.net Senior Software Engineer, APNIC sip: robertl@voip.apnic.net http://www.apnic.net/ phone: +61 7 3858 3100 From root@core3.amsl.com Thu Aug 19 12:30:42 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 866243A69EF; Thu, 19 Aug 2010 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100819193019.866243A69EF@core3.amsl.com> Date: Thu, 19 Aug 2010 12:30:02 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D ACTION:draft-ietf-sidr-cp-10.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: Thu, 19 Aug 2010 19:30:42 -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, D. Kong, K. Seo, R. Watro Filename : draft-ietf-sidr-cp-10.txt Pages : 39 Date : 2010-8-19 This document describes the certificate policy for a PKI used to support attestations about Internet resource holdings. Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a 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-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-cp-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-8-19122924.I-D@ietf.org> --NextPart-- From tim@ripe.net Fri Aug 20 07:02:17 2010 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 381AE3A68B3 for ; Fri, 20 Aug 2010 07:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_20=-0.74] 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 DRbqosuYNX1i for ; Fri, 20 Aug 2010 07:02:16 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id AF9863A67B4 for ; Fri, 20 Aug 2010 07:02:15 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OmSB9-0000nk-8T for sidr@ietf.org; Fri, 20 Aug 2010 16:02:49 +0200 Received: from timbru.vpn.ripe.net ([193.0.21.62] helo=guest-110.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OmSB9-00006Q-3g for sidr@ietf.org; Fri, 20 Aug 2010 16:02:43 +0200 Message-ID: <4C6E8B02.1070403@ripe.net> Date: Fri, 20 Aug 2010 16:02:42 +0200 From: Tim Bruijnzeels User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "sidr@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071946fe079e9b4c89304d42e9bc93634034 X-RIPE-Spam-Level: -- X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071946fe079e9b4c89304d42e9bc93634034 Subject: [sidr] RIPE NCC rpki validator online 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, 20 Aug 2010 14:02:17 -0000 Hi all, I just wanted to let you know that we published a new version of our rpki validator on RIPE Labs: http://labs.ripe.net/Members/agowland/ripe-ncc-validator-for-resource-certification It may be interesting for some on the people on this list as well. You are all invited to have a look, and feel free to comment on the article. 'RIPE Labs' is maintained by the RIPE NCC, but its target audience is the internet community as a whole, not just RIPE NCC members. The validator is a simple command line tool that will do top-down validation given a trust anchor, or bottom-up validation given a certificate or ROA (and a trust anchor). Currently only ROAs are supported (well, and certs, manifests and crls of course). Note that this tool is not like rcynic, or BBN's tool. This one is intended for ad-hoc testing, not proper and efficient caching, or communication using the RPKI-RTR protocol. We may extend it with this type of functionality, but if/when we do so depends on community feedback. Cheers, Tim From mlepinski@bbn.com Fri Aug 20 11:52:52 2010 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 49BEE3A6873 for ; Fri, 20 Aug 2010 11:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya7-Hoh2SqAB for ; Fri, 20 Aug 2010 11:52:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 5C58A3A6953 for ; Fri, 20 Aug 2010 11:52:51 -0700 (PDT) Received: from [128.89.254.57] (port=1226) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmWiT-000PlC-IL for sidr@ietf.org; Fri, 20 Aug 2010 14:53:25 -0400 Message-ID: <4C6ECF3A.4050803@bbn.com> Date: Fri, 20 Aug 2010 14:53:46 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Template for RPKI signed objects and revised ROA 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, 20 Aug 2010 18:52:52 -0000 A significant portion of the SIDR ROA-Format draft is spent specifying the ASN.1 syntax for the CMS encapsulation of the ROA object. (Note also that the SIDR manifest document also includes this ASN.1 syntax for an identical CMS encapsulation.) It was suggested to the authors of the ROA Format draft that the specification of any future RPKI signed objects would be made much simpler if we split the specification of the CMS encapsulation (which pertains to all RPKI signed objects) off from the stuff that is ROA-specific. Therefore, we have produced the two attached drafts for your consideration: draft-achi-rpki-signed-object is a generic template designed to simplify the specification of RPKI signed objects. Note that to instantiate the template and create a new type of RPKI signed object all you have to do is: 1. Get an OID to identify the ContentType for the new type of signed object 2. Specify the ASN.1 syntax for the content of the new type of signed object 3. Specify any additional steps that are required for validating the new type of signed object (beyond the standard steps required for all RPKI signed objects which are specified in the rpki-signed-object draft) draft-ietf-sidr-roa-format is a much shorter version of the roa-format draft which makes use of the generic signed object template and thus only specifies the ROA-specific stuff (that is, the three things I noted above). Note that breaking up the ROA-format document in this fashion in no way changes the syntax or semantics of a ROA (i.e., nothing has changes besides the manner of documentation). Please take a look at these documents and let us know if this is a good way forward. (If it is a good way forward we can easily change [i.e., shorten] the manifest document to use this signed-object template as well.) - Matt Lepinski From mlepinski@bbn.com Fri Aug 20 11:55:00 2010 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 39CC03A6847 for ; Fri, 20 Aug 2010 11:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9FEAr6oGzZD for ; Fri, 20 Aug 2010 11:54:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A61F43A67D0 for ; Fri, 20 Aug 2010 11:54:53 -0700 (PDT) Received: from [128.89.254.57] (port=1244) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmWkR-000Poj-NP for sidr@ietf.org; Fri, 20 Aug 2010 14:55:28 -0400 Message-ID: <4C6ECFB4.7050306@bbn.com> Date: Fri, 20 Aug 2010 14:55:48 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: multipart/mixed; boundary="------------060605070504060802080103" Subject: [sidr] Template for RPKI signed objects and revised ROA format [now with attachments!] 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, 20 Aug 2010 18:55:00 -0000 This is a multi-part message in MIME format. --------------060605070504060802080103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A significant portion of the SIDR ROA-Format draft is spent specifying the ASN.1 syntax for the CMS encapsulation of the ROA object. (Note also that the SIDR manifest document also includes this ASN.1 syntax for an identical CMS encapsulation.) It was suggested to the authors of the ROA Format draft that the specification of any future RPKI signed objects would be made much simpler if we split the specification of the CMS encapsulation (which pertains to all RPKI signed objects) off from the stuff that is ROA-specific. Therefore, we have produced the two attached drafts for your consideration: draft-achi-rpki-signed-object is a generic template designed to simplify the specification of RPKI signed objects. Note that to instantiate the template and create a new type of RPKI signed object all you have to do is: 1. Get an OID to identify the ContentType for the new type of signed object 2. Specify the ASN.1 syntax for the content of the new type of signed object 3. Specify any additional steps that are required for validating the new type of signed object (beyond the standard steps required for all RPKI signed objects which are specified in the rpki-signed-object draft) draft-ietf-sidr-roa-format is a much shorter version of the roa-format draft which makes use of the generic signed object template and thus only specifies the ROA-specific stuff (that is, the three things I noted above). Note that breaking up the ROA-format document in this fashion in no way changes the syntax or semantics of a ROA (i.e., nothing has changes besides the manner of documentation). Please take a look at these documents and let us know if this is a good way forward. (If it is a good way forward we can easily change [i.e., shorten] the manifest document to use this signed-object template as well.) - Matt Lepinski --------------060605070504060802080103 Content-Type: text/plain; name="draft-ietf-sidr-roa-format-08.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-sidr-roa-format-08.txt" Secure Inter-Domain Routing (sidr) M. Lepinski Internet Draft S. Kent Expires: February 20, 2011 D. Kong Intended Status: Proposed Standard BBN Technologies August 20, 2010 A Profile for Route Origin Authorizations (ROAs) draft-ietf-sidr-roa-format-08.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 28, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has Lepinski, Kent and Kong Expires February 2011 [Page 1] Internet-Draft Route Origin Authorizations August 2010 authorized an Autonomous System (AS) to originate routes to that one or more prefixes within the address block. Table of Contents 1. Introduction...................................................2 2. Basic Format........................Error! Bookmark not defined. 2.1. Signed-Data Content Type.......Error! Bookmark not defined. 2.1.1. version...................Error! Bookmark not defined. 2.1.2. digestAlgorithms..........Error! Bookmark not defined. 2.1.3. encapContentInfo..........Error! Bookmark not defined. 2.1.3.1. eContentType.........Error! Bookmark not defined. 2.1.3.2. eContent.............Error! Bookmark not defined. 2.1.3.2.1. version....................................4 2.1.3.2.2. asID.......................................4 2.1.3.2.3. ipAddrBlocks...............................4 2.1.4. certificates..............Error! Bookmark not defined. 2.1.5. crls......................Error! Bookmark not defined. 2.1.6. signerInfos...............Error! Bookmark not defined. 2.1.6.1. version..............Error! Bookmark not defined. 2.1.6.2. sid..................Error! Bookmark not defined. 2.1.6.3. digestAlgorithm......Error! Bookmark not defined. 2.1.6.4. signedAttrs..........Error! Bookmark not defined. 2.1.6.4.1. ContentType Attribute....Error! Bookmark not defined. 2.1.6.4.2. MessageDigest Attribute..Error! Bookmark not defined. 2.1.6.4.3. SigningTime Attribute....Error! Bookmark not defined. 2.1.6.4.4. BinarySigningTimeAttributeError! Bookmark not defined. 2.1.6.5. signatureAlgorithm...Error! Bookmark not defined. 2.1.6.6. signature............Error! Bookmark not defined. 2.1.6.7. unsignedAttrs........Error! Bookmark not defined. 3. ROA Validation.................................................5 4. Security Considerations........................................6 5. IANA Considerations............................................6 6. Acknowledgments................................................6 7. References.....................................................7 7.1. Normative References......................................7 7.2. Informative References....................................7 Authors' Addresses................................................8 Intellectual Property Statement...................................8 Disclaimer of Validity............................................8 Copyright Statement...............................................8 Lepinski, Kent and Kong Expires February 2011 [Page 2] Internet-Draft Route Origin Authorizations August 2010 1. Introduction The primary purpose of the Internet IP Address and AS Number Resource Public Key Infrastructure (RPKI) system is to improve routing security. As part of this system, a mechanism is needed to allow entities to verify that an AS has been given permission by an IP address block holder to advertise routes to one or more prefixes within that block. A ROA provides this function. The ROA makes use of the template for RPKI digitally signed objects [SIGN-OBJ], which defines a CMS wrapper for the ROA content as well as a generic validation procedure for RPKI signed objects. Therefore, to complete the specification of the ROA (see Section 4 of [SIGN- OBJ]), this document defines: 1. The OID that identifies the signed object as being a ROA. (This OID appears within the eContentType in the encapContentInfo object as well as the ContentType signed attribute in the signerInfo object.) 2. The ASN.1 syntax for the ROA eContent. (This is the payload that specifies the AS being authorized to originate routes as well as the prefixes to which the AS may originate routes.) 3. An additional step required to validate ROAs (in addition to the validation steps specified in [SIGN-OBJ]). 1.1. Terminology It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 2. The ROA ContentType The ContentType for a ROA is defined as routeOriginAttestation and has the numerical value of 1.2.840.113549.1.9.16.1.24. This OID must appear both within the eContentType in the encapContentInfo object as well as the ContentType signed attribute in the signerInfo object (see [SIGN-OBJ]). Lepinski, Kent and Kong Expires February 2011 [Page 3] Internet-Draft Route Origin Authorizations August 2010 3. The ROA eContent The content of a ROA identifies a single AS that has been authorized by the address space holder to originate routes and a list of one or more IP address prefixes that will be advertised. If the address space holder needs to authorize multiple ASes to advertise the same set of address prefixes, the holder issues multiple ROAs, one per AS number. A ROA is formally defined as: RouteOriginAttestation ::= SEQUENCE { version [0] INTEGER DEFAULT 0, asID ASID, ipAddrBlocks SEQUENCE OF ROAIPAddressFamily } ASID ::= INTEGER ROAIPAddressFamily ::= SEQUENCE { addressFamily OCTET STRING (SIZE (2..3)), addresses SEQUENCE OF ROAIPAddress } ROAIPAddress ::= SEQUENCE { address IPAddress, maxLength INTEGER OPTIONAL } IPAddress ::= BIT STRING Note that this content appears as the eContent within the encapContentInfo (see [SIGN-OBJ]). 3.1. version The version number of the RouteOriginAttestation MUST be 0. 3.2. asID The asID field contains the AS number that is authorized to originate routes to the given IP address prefixes. 3.3. ipAddrBlocks The ipAddrBlocks field encodes the set of IP address prefixes to which the AS is authorized to originate routes. Note that the syntax here is more restrictive than that used in the IP Address Delegation extension defined in RFC 3779. That extension can represent arbitrary address ranges, whereas ROAs need to represent only prefixes. Lepinski, Kent and Kong Expires February 2011 [Page 4] Internet-Draft Route Origin Authorizations August 2010 Within the ROAIPAddressFamily structure, addressFamily contains the Address Family Identifier (AFI) of an IP address family. This specification only supports IPv4 and IPv6. Therefore, addressFamily MUST be either 0001 or 0002. Within a ROAIPAddress structure, the addresses field represents prefixes as a sequence of type IPAddress. (See [RFC3779] for more details). If present, the maxLength must be an integer greater than or equal to the length of the accompanying prefix and less than or equal to the length (in bits) of an IP address in the address family (32 for IPv4 and 128 for IPv6). When present, the maxLength specifies the maximum length of IP address prefix that the AS is authorized to advertise. (For example, if the IP Address prefix is 10.0/16 and the maxLength is 24, the AS is authorized to advertise any more specific prefix having length at most 24. That is, in this example, the AS would be authorized to advertise 10.0/16, 10.0.128/20, or 10.0.255/24, but not 10.0.255.0/25.) When the maxLength is not present, the AS is only authorized to advertise exactly the prefix specified in the ROA. Note that a valid ROA may contain an IP Address prefix (within a ROAIPAddress element) that is encompassed by another IP Address prefix (within a separate ROAIPAddress element). For example, a ROA may contain the prefix 10.0/16 with maxLength 18, as well as the prefix 10.0.0/24 with maxLength 24. (Such a ROA would authorize the indicated AS to advertise any prefix beginning with 10.0 with length at least 16 and no greater than 18, as well as the specific prefix 10.0.0/24.) Additionally, a ROA MAY contain two ROAIPAddress elements where the IP Address prefix is identical in both cases. However, this is NOT RECOMMENDED as in such a case the ROAIPAddress with the shorter maxLength grants no additional privileges to the indicated AS and thus can be omitted without changing the meaning of the ROA. 4. ROA Validation Before a relying party can use a ROA to validate a routing announcement, the relying party must first validate the ROA. To validate a ROA the relying party MUST perform all the validation checks specified in [SIGN-OBJ] as well as the following additional ROA-specific validation step. 1. The IP Address Delegation extension [RFC3779] is present in the EE certificate (contained within the ROA) and each IP address prefix(es) in ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension. Lepinski, Kent and Kong Expires February 2011 [Page 5] Internet-Draft Route Origin Authorizations August 2010 5. Security Considerations There is no assumption of confidentiality for the data in a ROA; it is anticipated that ROAs will be stored in repositories that are accessible to all ISPs, and perhaps to all Internet users. There is no explicit authentication associated with a ROA, since the PKI used for ROA validation provides authorization but not authentication. Although the ROA is a signed, application layer object, there is no intent to convey non-repudiation via a ROA. The purpose of a ROA is to convey authorization for an AS to originate a route to the prefix(es) in the ROA. Thus the integrity of a ROA must be established. The ROA makes use of the CMS signed message format for integrity, and thus inherits the security considerations associated with that data structure. The right of the ROA signer to authorize the target AS to originate routes to the prefix(es) is established through use of the address space and AS number PKI described in [ARCH]. Specifically one must verify the signature on the ROA using an X.509 certificate issued under this PKI, and check that the prefix(es) in the ROA match those in the address space extension in the certificate. 6. IANA Considerations None. 7. Acknowledgments The authors wish to thank Charles Gardiner and Russ Housley for their help and contributions. Additionally, the authors would like to thank Rob Austein, Roque Gagliano, Danny McPherson and Sam Weiler for their careful reviews and helpful comments. Lepinski, Kent and Kong Expires February 2011 [Page 6] Internet-Draft Route Origin Authorizations August 2010 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3852] Housley, R., "Cryptographic Message Syntax", RFC 3852, July 2004. [RFC3779] Lynn, C., Kent, S., and Seo, K., "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [ALGS] Huston, G., "A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure", draft-ietf- sidr-rpki-alg, May 2010 [RESCERT] Huston, G., Michaelson, G., and Loomans, R., "A Profile for X.509 PKIX Resource Certificates", draft-ietf-sidr-res- certs, May 2010. [SIGNOBJ] Lepinski, M., Chi, A., and Kent, S., "Generic Signed Objects for the Resource Public Key Infrastructure", draft- achi-rpki-signed-object, August 2010. 8.2. Informative References [ARCH] Lepinski, M. and Kent, S., "An Infrastructure to Support Secure Internet Routing," draft-ietf-sidr-arch, July 2010. [CP] Seo, K., et. al., "A Certificate Policy for the Resource PKI," draft-ietf-sidr-cp, July 2010. [REPOS] Huston, G., Michaelson, G., and Loomans, R., "A Profile for Resource Certificate Repository Structure", draft-ietf- sidr-repos-struct, May 2010. [RFC4049] Housley, R., "BinaryTime: An Alternative Format for Representing Time in ASN.1," RFC 4049, April 2005. Lepinski, Kent and Kong Expires February 2011 [Page 7] Internet-Draft Route Origin Authorizations August 2010 Authors' Addresses Matt Lepinski BBN Technologies 10 Moulton Street Cambridge MA 02138 Email: mlepinski@bbn.com Stephen Kent BBN Technologies 10 Moulton Street Cambridge MA 02138 Email: skent@bbn.com Derrick Kong BBN Technologies 10 Moulton Street Cambridge MA 02138 Email: dkong@bbn.com Pre-5378 Material Disclaimer This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Lepinski, Kent and Kong Expires February 2011 [Page 8] --------------060605070504060802080103 Content-Type: text/plain; name="draft-achi-rpki-signed-object-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-achi-rpki-signed-object-00.txt" Secure Inter-Domain Routing M. Lepinski Internet-Draft A. Chi Intended status: Standards Track S. Kent Expires: February 21, 2011 BBN August 20, 2010 Signed Object Template for the Resource Public Key Infrastructure draft-achi-rpki-signed-object-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure. These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. Lepinski, et al. Expires February 21, 2011 [Page 1] Internet-Draft RPKI Signed Object Template August 20, 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Note on Algorithms . . . . . . . . . . . . . . . . . . . . 3 2. Signed Object Syntax . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 4 2.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. digestAlgorithms . . . . . . . . . . . . . . . . . . . 4 2.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 5 2.1.3.1. eContentType . . . . . . . . . . . . . . . . . . 5 2.1.3.2. eContent . . . . . . . . . . . . . . . . . . . . 5 2.1.4. certificates . . . . . . . . . . . . . . . . . . . . . 5 2.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.6. signerInfos . . . . . . . . . . . . . . . . . . . . . 6 2.1.6.1. version . . . . . . . . . . . . . . . . . . . . . 6 2.1.6.2. sid . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.6.3. digestAlgorithm . . . . . . . . . . . . . . . . . 6 2.1.6.4. signedAttrs . . . . . . . . . . . . . . . . . . . 6 2.1.6.4.1. Content-Type Attribute . . . . . . . . . . . 7 2.1.6.4.2. Message-Digest Attribute . . . . . . . . . . 7 2.1.6.4.3. SigningTime Attribute . . . . . . . . . . . 7 2.1.6.4.4. BinarySigningTime Attribute . . . . . . . . 8 2.1.6.5. signatureAlgorithm . . . . . . . . . . . . . . . 8 2.1.6.6. signature . . . . . . . . . . . . . . . . . . . . 8 2.1.6.7. unsignedAttrs . . . . . . . . . . . . . . . . . . 8 3. Signed Object Validation . . . . . . . . . . . . . . . . . . . . 9 4. Definition of Specific Signed Objects . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 9. Informative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Lepinski, et al. Expires February 21, 2011 [Page 2] Internet-Draft RPKI Signed Object Template August 20, 2010 1. Introduction The purpose of the Internet IP Address and AS Number Resource Public Key Infrastructure (RPKI) system is to support assertions by current resource holders of IP (v4 and v6) address space and AS numbers, based on the records of the organizations that act as CAs. IP address and AS number resource information is carried in X.509 certificates via RFC 3779 extensions [I-D.sidr-res-certs]. Other information assertions about resources are expressed via digitally signed, non-X.509 data structures that are referred to as "signed objects" in the RPKI context [I-D.sidr-arch]. This document standardizes a template for specifying signed objects that can be validated using the RPKI. RPKI signed objects make use of Cryptographic Message Syntax (CMS) [RFC5652] as a standard encapsulation format. CMS was chosen to take advantage of existing open source software available for processing messages in this format. RPKI signed objects adhere to a profile (specified in Section 2) of the CMS signed-data object. The template defined in this document for RPKI signed objects is not a complete specification for any particular type of signed object, and instead includes only the items which are common to all RPKI signed objects. That is, fully specifying a particular type of signed object requires an additional document that specifies the details which are specific to a particular type of signed object (such as ASN.1 syntax for the object's payload and any additional steps required to validate the particular type of signed object). Section 4 describes in more detail the additional pieces that must be specified in order to define a new type of RPKI signed object that uses this template. Additionally, see [draft-ietf-sidr-roa-format] for an example of a document that uses this template to specify a particular type of signed object, the Route Origination Authorization. 1.1. Terminology It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1.2. Note on Algorithms Cryptographic Message Syntax is a general format capable of Lepinski, et al. Expires February 21, 2011 [Page 3] Internet-Draft RPKI Signed Object Template August 20, 2010 accommodating a wide variety of signature and digest algorithms. The algorithms used in the RPKI (and associated key sizes) are specified in [I-D.sidr-rpki-algs]. 2. Signed Object Syntax The RPKI signed object is a profile of the Cryptographic Message Syntax (CMS) [RFC5652] signed-data object. The general format of a CMS object is: ContentInfo ::= SEQUENCE { contentType ContentType, content [0] EXPLICIT ANY DEFINED BY contentType } ContentType ::= OBJECT IDENTIFIER The ContentType is the signed-data type of id-data, namely the id- signedData OID, 1.2.840.113549.1.7.2. [RFC5652] 2.1. Signed-Data Content Type According to the CMS standard, the signed-data content type is the ASN.1 type SignedData: SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos } DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier SignerInfos ::= SET OF SignerInfo Additionally, the SignerInfos set must contain only a single SignerInfo object. 2.1.1. version The version is the syntax version number. It MUST be 3, corresponding to the signerInfo structure having version number 3. 2.1.2. digestAlgorithms The digestAlgorithms set contains the OIDs of the digest algorithm(s) used in signing the encapsulated content. This set MUST contain Lepinski, et al. Expires February 21, 2011 [Page 4] Internet-Draft RPKI Signed Object Template August 20, 2010 exactly one digest algorithm OID, and the OID MUST be selected from those specified in [I-D.sidr-rpki-algs]. 2.1.3. encapContentInfo encapContentInfo is the signed content, consisting of a content type identifier and the content itself. The encapContentInfo represents the payload of the RPKI signed object. EncapsulatedContentInfo ::= SEQUENCE { eContentType ContentType, eContent [0] EXPLICIT OCTET STRING OPTIONAL } ContentType ::= OBJECT IDENTIFIER 2.1.3.1. eContentType This field is left undefined by this profile. The eContentType is an OID specifying the type of payload in this signed object and MUST be specified by the document that defines the object. 2.1.3.2. eContent This field is left partially undefined by this profile. The eContent is the payload of the signed object and MUST be specified by the document that defines the RPKI object. At the outermost level, the eContent field MUST be an ASN.1 SEQUENCE. The first element of the sequence MUST be the version number, in order to enable transition to new versions of signed objects over time. ContentTemplate ::= SEQUENCE { version [0] INTEGER DEFAULT 0, ... } The document that defines the specific RPKI object MUST specify the remaining fields, represented as ellipses (...). 2.1.4. certificates The certificates field MUST be included, and MUST contain exactly one certificate, RPKI EE certificate needed to validate this signed object. 2.1.5. crls The crls field MUST be omitted. Lepinski, et al. Expires February 21, 2011 [Page 5] Internet-Draft RPKI Signed Object Template August 20, 2010 2.1.6. signerInfos SignerInfo is defined under CMS as: SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 2.1.6.1. version The version number MUST be 3, corresponding with the choice of SubjectKeyIdentifier for the sid. 2.1.6.2. sid The sid is defined as: SignerIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier [0] SubjectKeyIdentifier } For RPKI signed objects, the sid MUST be the SubjectKeyIdentifier that appears in the EE certificate carried in the CMS certificates field. 2.1.6.3. digestAlgorithm The digestAlgorithm MUST consist of the OID of a digest algorithm that conforms to the RPKI Algorithms and Key Size Profile specification [I-D.sidr-rpki-algs]. 2.1.6.4. signedAttrs The signedAttrs is defined as: SignedAttributes ::= SET SIZE (1..MAX) OF Attribute Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } AttributeValue ::= ANY Lepinski, et al. Expires February 21, 2011 [Page 6] Internet-Draft RPKI Signed Object Template August 20, 2010 The signedAttr element MUST be present and MUST include the content- type and message-digest attributes. The signer MAY also include the signing-time signed attribute, the binary-signing-time signed attribute, or both signing-time attributes. Other signed attributes MUST NOT be included. The signedAttr MUST include only a single instance of any particular attribute. Additionally, even though the syntax allows for a SET OF AttributeValue, in an RPKI signed object the attrValues MUST consist of only a single AttributeValue. 2.1.6.4.1. Content-Type Attribute The ContentType attribute MUST be present. The attrType OID for the ContentType attribute is 1.2.840.113549.1.9.3. The attrValues for the ContentType attribute MUST match the eContentType in the EncapsulatedContentInfo. Thus, attrValues must contain the OID that specifies the payload type of the specific RPKI signed object carried in the CMS signed data structure. 2.1.6.4.2. Message-Digest Attribute The MessageDigest Attribute MUST be present. The attrType OID for the MessageDigest Attribute is 1.2.840.113549.1.9.4. The attrValues for the MessageDigest attribute contains the output of the digest algorithm applied to the content being signed, as specified in Section 11.1 of [RFC5652]. 2.1.6.4.3. SigningTime Attribute The SigningTime Attribute MAY be present. Note that the presence or absence of the SigningTime attribute MUST NOT affect the validity of the signed object (as specified in Section 3). The attrType OID for the SigningTime attribute is 1.2.840.113549.1.9.5. id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } The attrValues for the SigningTime attribute is defined as: SigningTime ::= Time Time ::= CHOICE { utcTime UTCTime, generalizedTime GeneralizedTime } Lepinski, et al. Expires February 21, 2011 [Page 7] Internet-Draft RPKI Signed Object Template August 20, 2010 The Time element specifies the time, based on the local system clock, at which the digital signature was applied to the content. The definition of Time matches the one specified in the 1997 version of X.509. Additional information regarding the use of UTCTime and GeneralizedTime can be found in [RFC5652]. 2.1.6.4.4. BinarySigningTime Attribute The BinarySigningTime Attribute MAY be present. Note that the presence or absence of the BinarySigningTime attribute in no way affects the validity of the signed object (as specified in Section 3). The attrType OID for the SigningTime attribute is 1.2.840.113549.1.9.16.2.46. id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 46 } The attrValues for the SigningTime attribute is defined as: BinarySigningTime ::= BinaryTime BinaryTime ::= INTEGER (0..MAX) The BinaryTime element specifies the time, based on the local system clock, at which the digital signature was applied to the content. The precise definition of the BinaryTime element can be found in [RFC4049]. 2.1.6.5. signatureAlgorithm The signatureAlgorithm MUST conform to the RPKI Algorithms and Key Size Profile specification [I-D.sidr-rpki-algs]. 2.1.6.6. signature The signature value is defined as: SignatureValue ::= OCTET STRING The signature characteristics are defined by the digest and signature algorithms. 2.1.6.7. unsignedAttrs unsignedAttrs MUST be omitted. Lepinski, et al. Expires February 21, 2011 [Page 8] Internet-Draft RPKI Signed Object Template August 20, 2010 3. Signed Object Validation Before a relying party can use a signed object, the relying party MUST validate the signed object by verifying that all of the following conditions hold. A relying party may perform these checks in any order. Note that these checks are necessary but not sufficient: in general, further validation MUST be performed based on the specific type of signed object. 1. The signed object syntax complies with this specification. In particular, that each of the following is true: a. The contentType of the CMS object is SignedData (OID 1.2.840.113549.1.7.2) b. The version of the SignedData object is 3. c. The certificates field in the SignedData object is present and contains one EE certificate, the Subject Key Identifier (SKI) field of which matches the sid field of the SignerInfo object. d. The crls field in the SignedData object is omitted. e. The version of the SignerInfo is 3. f. The signedAttrs field in the SignerInfo object is present and contains both the ContentType attribute (OID 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 1.2.840.113549.1.9.4). g. The eContentType in the EncapsulatedContentInfo is an OID that matches the attrValues in the ContentType attribute. h. The unsignedAttrs field in the SignerInfo object is omitted. i. The digestAlgorithm in the SignedData and SignerInfo objects conforms to the RPKI Algorithms and Key Size Profile specification [I-D.sidr-rpki-algs]. j. The signatureAlgorithm in the SignerInfo object conforms to the RPKI Algorithms and Key Size Profile specification [I-D.sidr-rpki-algs]. 2. The public key of the EE certificate (contained within the CMS signed-data object) can be used to successfully verify the signature on the signed object. Lepinski, et al. Expires February 21, 2011 [Page 9] Internet-Draft RPKI Signed Object Template August 20, 2010 3. The EE certificate (contained within the CMS signed-data object) is a valid end-entity certificate in the resource PKI as specified by [I-D.sidr-res-certs]. In particular, there exists a valid certification path from a trust anchor to this EE certificate. If the above procedure indicates that the signed object is invalid, then the signed object MUST be discarded and treated as though no signed object were present. If the all of the conditions above are true, then the signed object may be valid. The relying party MUST then perform any additional validation steps required for the particular type of signed object. 4. Definition of Specific Signed Objects Each RPKI signed object MUST be defined based on this profile, by specifying the following data elements and validation procedure: 1. eContentType: Obtain an OID to be used for the eContentType field in encapContentInfo. This OID uniquely identifies the type of signed object. 2. eContent: Define an ASN.1 syntax for the eContent field in encapContentInfo. The syntax must consist of an ASN.1 SEQUENCE whose first element is "version" expressed as an ASN.1 INTEGER. 3. Content-Type Attribute: The mandatory Content-Type Attribute must have its attrValues field set to the same OID as eContentType in item 1. 4. Additional Validation: Define a set of additional validation steps for the specific signed object. Before using this specific signed object, a relying party MUST perform both the generic validation steps in Section 3 above, as well as these additional steps. 5. Security Considerations There is no assumption of confidentiality for the data in an RPKI signed object. The integrity and authenticity of each signed object is based on the verification of a digital signature for the object, and on the validation of the EE certificate used to perform that verification. It is anticipated that signed objects will be stored in repositories that will be publicly accessible. 6. IANA Considerations None. Lepinski, et al. Expires February 21, 2011 [Page 10] Internet-Draft RPKI Signed Object Template August 20, 2010 7. Acknowledgements The authors wish to thank Charles Gardiner, Russ Housley, and Derek Kong for their help and contributions. Additionally, the authors would like to thank Rob Austein, Roque Gagliano, Danny McPherson and Sam Weiler for their careful reviews and helpful comments. 8. Normative References [I-D.sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", draft-ietf-sidr-arch-09.txt (work in progress), October 2009. [I-D.sidr-res-certs] Huston, G., Michaleson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs-18.txt (work in progress), May 2010. [I-D.sidr-rpki-algs] Huston, G., "A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure", draft-huston-sidr-rpki-algs-00.txt (work in progress), July 2009. [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009. 9. Informative References [RFC4049] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 4049, April 2005. Authors' Addresses Matt Lepinski BBN Technologies 10 Moulton Street Cambridge MA 02138 Lepinski, et al. Expires February 21, 2011 [Page 11] Internet-Draft RPKI Signed Object Template August 20, 2010 Email: mlepinski@bbn.com Andrew Chi BBN Technologies 10 Moulton Street Cambridge MA 02138 Email: achi@bbn.com Stephen Kent BBN Technologies 10 Moulton Street Cambridge MA 02138 Email: kent@bbn.com Lepinski, et al. Expires February 21, 2011 [Page 12] --------------060605070504060802080103-- From randy@psg.com Fri Aug 20 13:06:21 2010 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 28C103A68B6 for ; Fri, 20 Aug 2010 13:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 vERChcUP1PPi for ; Fri, 20 Aug 2010 13:06:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 1F5E53A69EF for ; Fri, 20 Aug 2010 13:06:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmXrY-000J1U-U4; Fri, 20 Aug 2010 20:06:53 +0000 Date: Sat, 21 Aug 2010 05:06:52 +0900 Message-ID: From: Randy Bush To: Matt Lepinski In-Reply-To: <4C6ECF3A.4050803@bbn.com> References: <4C6ECF3A.4050803@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@ietf.org Subject: Re: [sidr] Template for RPKI signed objects and revised ROA 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, 20 Aug 2010 20:06:21 -0000 > It was suggested to the authors of the ROA Format draft that the > specification of any future RPKI signed objects would be made much > simpler if we split the specification of the CMS encapsulation (which > pertains to all RPKI signed objects) off from the stuff that is > ROA-specific. > > Therefore, we have produced the two attached drafts for your consideration: thank you! randy From randy@psg.com Fri Aug 20 13:18:37 2010 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 A55B63A68CC for ; Fri, 20 Aug 2010 13:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 hsDoS2WjM6sS for ; Fri, 20 Aug 2010 13:18:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A63483A659C for ; Fri, 20 Aug 2010 13:18:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmY3S-000J40-Ld; Fri, 20 Aug 2010 20:19:10 +0000 Date: Sat, 21 Aug 2010 05:19:09 +0900 Message-ID: From: Randy Bush To: Matt Lepinski In-Reply-To: <4C6ECF3A.4050803@bbn.com> References: <4C6ECF3A.4050803@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@ietf.org Subject: Re: [sidr] Template for RPKI signed objects and revised ROA 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, 20 Aug 2010 20:18:37 -0000 > draft-achi-rpki-signed-object is a generic template designed to simplify > the specification of RPKI signed objects. > Note that to instantiate the template and create a new type of RPKI > signed object all you have to do is: > 1. Get an OID to identify the ContentType for the new type of > signed object > 2. Specify the ASN.1 syntax for the content of the new type of > signed object > 3. Specify any additional steps that are required for validating > the new type of signed object (beyond the standard steps required for > all RPKI signed objects which are specified in the rpki-signed-object draft) sandy/chris, could we please quickly adopt this as a wg draft so that this syntactic split of roa-format does not create delay? randy From Sandra.Murphy@cobham.com Mon Aug 23 07:47:11 2010 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 93C0D3A6A62 for ; Mon, 23 Aug 2010 07:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.187 X-Spam-Level: X-Spam-Status: No, score=-101.187 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2NJQNznxNQm for ; Mon, 23 Aug 2010 07:47:10 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 93C903A6A5C for ; Mon, 23 Aug 2010 07:47: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 o7NElhc3021465 for ; Mon, 23 Aug 2010 09:47: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 o7NEli2C009468 for ; Mon, 23 Aug 2010 09:47:44 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([10.71.0.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Aug 2010 10:47:43 -0400 Date: Mon, 23 Aug 2010 10:47:42 -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: 23 Aug 2010 14:47:43.0406 (UTC) FILETIME=[248E44E0:01CB42D2] Subject: [sidr] WG adoption of draft-achi-rpki-signed-object-00.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: Mon, 23 Aug 2010 14:47:11 -0000 The working group chairs have received a request from the authors of draft-achi-rpki-signed-object-00.txt that the working group adopt this internet draft as a work item. This is the draft to which Matt Lepinski alluded in his message of 20 Aug 2010. As he notes, this draft is an extract of the common language from the ROA format and manifest documents that has to do with the CMS encapsulation for signed objects. Note that the draft from which the language was extracted are already working group work items. The work item represented by this new draft is the creation of an extract and a generic description. The draft is available at http://tools.ietf.org/html/draft-achi-rpki-signed-object-00 As always in a call for adoption: Recall that active support for adoption is necessary for the wg chairs to judge acceptance as a working group work item, so silence works against adoption. The wg chairs also want to know who would be willing to work on the draft. Please respond to the list, giving your recommendation for or against adoption of the draft as a wg work item. Because of the special circumstances of this draft, the call for adoption will be shorter than usual - 10 days, ending 1 Sept 2010. --Sandy, speaking as wg chair From gih@apnic.net Mon Aug 23 13:30:33 2010 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 D07F03A6844 for ; Mon, 23 Aug 2010 13:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.232 X-Spam-Level: X-Spam-Status: No, score=-101.232 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RELAY_IS_203=0.994, 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 PwAahxZm0DKd for ; Mon, 23 Aug 2010 13:30:32 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id F02B13A6AFA for ; Mon, 23 Aug 2010 13:30:28 -0700 (PDT) Received: from dhcp71.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 66A56D58C4; Tue, 24 Aug 2010 06:30:47 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Tue, 24 Aug 2010 06:30:42 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy X-Mailer: Apple Mail (2.1081) Cc: Adrian Farrel , "sidr@ietf.org wg" Subject: Re: [sidr] WG adoption 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, 23 Aug 2010 20:30:34 -0000 The Working Group chairs have also received a request from the authors = of draft-huston-sidr-keyroll-00.txt on the 26th July that the working = group adopt this internet draft as a work item, and a followup in = support of this request from a working group member on the 4th August. Would the WG chairs please act on this earlier request, or kindly = indicate the exact nature of procedural errors in the earlier request so = that the authors may redress them to the extent possible? On 24/08/2010, at 12:47 AM, Sandra Murphy wrote: > The working group chairs have received a request from the authors of = draft-achi-rpki-signed-object-00.txt that the working group adopt this = internet draft as a work item. >=20 > This is the draft to which Matt Lepinski alluded in his message of 20 = Aug 2010. As he notes, this draft is an extract of the common language = from the ROA format and manifest documents that has to do with the CMS = encapsulation for signed objects. >=20 > Note that the draft from which the language was extracted are already = working group work items. The work item represented by this new draft = is the creation of an extract and a generic description. >=20 > The draft is available at = http://tools.ietf.org/html/draft-achi-rpki-signed-object-00 >=20 > As always in a call for adoption: >=20 > Recall that active support for adoption is necessary for the wg chairs = to > judge acceptance as a working group work item, so silence works = against > adoption. The wg chairs also want to know who would be willing to = work on > the draft. >=20 > Please respond to the list, giving your recommendation for or against > adoption of the draft as a wg work item. >=20 > Because of the special circumstances of this draft, the call for = adoption will be shorter than usual - 10 days, ending 1 Sept 2010. >=20 > --Sandy, speaking as wg chair >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Mon Aug 23 15:13:39 2010 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 95FB83A6958 for ; Mon, 23 Aug 2010 15:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 3vyR01+RlqUj for ; Mon, 23 Aug 2010 15:13:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 4B8B83A684D for ; Mon, 23 Aug 2010 15:13:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OnfHO-0005Ec-PC; Mon, 23 Aug 2010 22:14:10 +0000 Date: Tue, 24 Aug 2010 07:14:10 +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] WG adoption of draft-achi-rpki-signed-object-00.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: Mon, 23 Aug 2010 22:13:39 -0000 > The working group chairs have received a request from the authors of > draft-achi-rpki-signed-object-00.txt that the working group adopt this > internet draft as a work item. support randy From rbarnes@bbn.com Mon Aug 23 17:56:33 2010 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 946D33A6B47 for ; Mon, 23 Aug 2010 17:56: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.146, 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 zWJ3LDR77xtb for ; Mon, 23 Aug 2010 17:56:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6D11A3A6B3F for ; Mon, 23 Aug 2010 17:56:32 -0700 (PDT) Received: from [128.89.254.122] (port=55866 helo=[192.168.1.43]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Onhp3-000OAo-Ee; Mon, 23 Aug 2010 20:57:05 -0400 Message-Id: From: "Richard L. Barnes" To: Randy Bush In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 20:57:02 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Sandra Murphy , sidr@ietf.org Subject: Re: [sidr] WG adoption of draft-achi-rpki-signed-object-00.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: Tue, 24 Aug 2010 00:56:33 -0000 +1 This document seems like a good approach to maintaining some sort of long-term architectural sanity in the RPKI, maybe even something that could simplify tool-building. --Richard On Aug 23, 2010, at 6:14 PM, Randy Bush wrote: >> The working group chairs have received a request from the authors of >> draft-achi-rpki-signed-object-00.txt that the working group adopt >> this >> internet draft as a work item. > > support > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From terry.manderson@icann.org Mon Aug 23 21:20:47 2010 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 3F9AF3A681D for ; Mon, 23 Aug 2010 21:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.981 X-Spam-Level: X-Spam-Status: No, score=-105.981 tagged_above=-999 required=5 tests=[AWL=0.618, 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 L-3ZZJufTZWB for ; Mon, 23 Aug 2010 21:20:46 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 5FCFA3A6405 for ; Mon, 23 Aug 2010 21:20: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; Mon, 23 Aug 2010 21:21:19 -0700 From: Terry Manderson To: Sandra Murphy , "sidr@ietf.org" Date: Mon, 23 Aug 2010 21:21:18 -0700 Thread-Topic: [sidr] WG adoption of draft-achi-rpki-signed-object-00.txt Thread-Index: ActC0jN25nlGIx/oTaGKhV+H4AdhmwAcZjeZ 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 Subject: Re: [sidr] WG adoption of draft-achi-rpki-signed-object-00.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: Tue, 24 Aug 2010 04:20:47 -0000 Support, and willing to review. Cheers Terry On 24/08/10 12:47 AM, "Sandra Murphy" wrote: > The working group chairs have received a request from the authors of > draft-achi-rpki-signed-object-00.txt that the working group adopt this > internet draft as a work item. >=20 > This is the draft to which Matt Lepinski alluded in his message of 20 Aug > 2010. As he notes, this draft is an extract of the common language from > the ROA format and manifest documents that has to do with the CMS > encapsulation for signed objects. >=20 > Note that the draft from which the language was extracted are already > working group work items. The work item represented by this new draft is > the creation of an extract and a generic description. >=20 > The draft is available at > http://tools.ietf.org/html/draft-achi-rpki-signed-object-00 >=20 > As always in a call for adoption: >=20 > Recall that active support for adoption is necessary for the wg chairs to > judge acceptance as a working group work item, so silence works against > adoption. The wg chairs also want to know who would be willing to work o= n > the draft. >=20 > Please respond to the list, giving your recommendation for or against > adoption of the draft as a wg work item. >=20 > Because of the special circumstances of this draft, the call for adoption > will be shorter than usual - 10 days, ending 1 Sept 2010. >=20 > --Sandy, speaking as wg chair >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kseo@bbn.com Tue Aug 24 06:19:49 2010 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 5719E3A69D2 for ; Tue, 24 Aug 2010 06:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5jo796SChwf for ; Tue, 24 Aug 2010 06:19:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6C2203A681B for ; Tue, 24 Aug 2010 06:19:45 -0700 (PDT) Received: from dhcp89-089-222.bbn.com ([128.89.89.222]:49382 helo=[192.168.1.2]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OntQI-0002pa-3V; Tue, 24 Aug 2010 09:20:18 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 24 Aug 2010 09:20:16 -0400 To: Sandra Murphy From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] WG adoption of draft-achi-rpki-signed-object-00.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: Tue, 24 Aug 2010 13:19:49 -0000 I support this. >The working group chairs have received a request from the authors of >draft-achi-rpki-signed-object-00.txt that the working group adopt >this internet draft as a work item. > >This is the draft to which Matt Lepinski alluded in his message of >20 Aug 2010. As he notes, this draft is an extract of the common >language from the ROA format and manifest documents that has to do >with the CMS encapsulation for signed objects. > >Note that the draft from which the language was extracted are >already working group work items. The work item represented by this >new draft is the creation of an extract and a generic description. > >The draft is available at >http://tools.ietf.org/html/draft-achi-rpki-signed-object-00 > >As always in a call for adoption: > >Recall that active support for adoption is necessary for the wg chairs to >judge acceptance as a working group work item, so silence works against >adoption. The wg chairs also want to know who would be willing to work on >the draft. > >Please respond to the list, giving your recommendation for or against >adoption of the draft as a wg work item. > >Because of the special circumstances of this draft, the call for >adoption will be shorter than usual - 10 days, ending 1 Sept 2010. > >--Sandy, speaking as wg chair > > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From robert@ripe.net Tue Aug 24 07:01:56 2010 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 C63CA3A697D for ; Tue, 24 Aug 2010 07:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvabB+1217a0 for ; Tue, 24 Aug 2010 07:01:55 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 63A0F3A69E7 for ; Tue, 24 Aug 2010 07:01:55 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Onu4y-0002qP-5z for sidr@ietf.org; Tue, 24 Aug 2010 16:02:26 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=Kistel-Mac.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Onu4y-0002yd-1d for sidr@ietf.org; Tue, 24 Aug 2010 16:02:20 +0200 Message-ID: <4C73D0EB.2000808@ripe.net> Date: Tue, 24 Aug 2010 16:02:19 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a27489c2ee3695e22578aef9e16caa02ea4e X-RIPE-Spam-Level: -- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a27489c2ee3695e22578aef9e16caa02ea4e Subject: Re: [sidr] WG adoption of draft-achi-rpki-signed-object-00.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: Tue, 24 Aug 2010 14:01:56 -0000 Generally I support this too, but have a specific question: what's the intended future relation between this would-be-draft and the existing ROA draft? I mean, once we have a template, we should use that, even for the ROAs, right? Robert On 2010.08.23. 16:47, Sandra Murphy wrote: > The working group chairs have received a request from the authors of > draft-achi-rpki-signed-object-00.txt that the working group adopt this > internet draft as a work item. > > This is the draft to which Matt Lepinski alluded in his message of 20 Aug > 2010. As he notes, this draft is an extract of the common language from the > ROA format and manifest documents that has to do with the CMS encapsulation > for signed objects. > > Note that the draft from which the language was extracted are already > working group work items. The work item represented by this new draft is the > creation of an extract and a generic description. > > The draft is available at > http://tools.ietf.org/html/draft-achi-rpki-signed-object-00 > > As always in a call for adoption: > > Recall that active support for adoption is necessary for the wg chairs to > judge acceptance as a working group work item, so silence works against > adoption. The wg chairs also want to know who would be willing to work on > the draft. > > Please respond to the list, giving your recommendation for or against > adoption of the draft as a wg work item. > > Because of the special circumstances of this draft, the call for adoption > will be shorter than usual - 10 days, ending 1 Sept 2010. > > --Sandy, speaking as wg chair > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Tue Aug 24 07:44:18 2010 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 021C63A6A2E for ; Tue, 24 Aug 2010 07:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 BnFXTJYJt5AT for ; Tue, 24 Aug 2010 07:44:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 049643A6AE6 for ; Tue, 24 Aug 2010 07:44:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Onuk4-0008SC-7i; Tue, 24 Aug 2010 14:44:48 +0000 Date: Tue, 24 Aug 2010 23:44:47 +0900 Message-ID: From: Randy Bush To: Robert Kisteleki In-Reply-To: <4C73D0EB.2000808@ripe.net> References: <4C73D0EB.2000808@ripe.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@ietf.org Subject: Re: [sidr] WG adoption of draft-achi-rpki-signed-object-00.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: Tue, 24 Aug 2010 14:44:18 -0000 > Generally I support this too, but have a specific question: what's the > intended future relation between this would-be-draft and the existing ROA > draft? I mean, once we have a template, we should use that, even for the > ROAs, right? i have been told that is the plan. i certainly hope so. randy From rogaglia@cisco.com Tue Aug 24 07:54:29 2010 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 12F8E3A6B24 for ; Tue, 24 Aug 2010 07:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.352 X-Spam-Level: X-Spam-Status: No, score=-10.352 tagged_above=-999 required=5 tests=[AWL=0.247, 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 QbQb-NBTPXWz for ; Tue, 24 Aug 2010 07:54:27 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 592D23A6B11 for ; Tue, 24 Aug 2010 07:54:27 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF56c0xAZnwN/2dsb2JhbACgQHGfK5tohTcEiXg X-IronPort-AV: E=Sophos;i="4.56,263,1280707200"; d="p7s'?scan'208";a="151316706" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2010 14:55:00 +0000 Received: from [144.254.21.53] ([144.254.21.53]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7OEsxg2028885; Tue, 24 Aug 2010 14:54:59 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-180--588178771; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: <4C73D0EB.2000808@ripe.net> Date: Tue, 24 Aug 2010 16:54:58 +0200 Message-Id: References: <4C73D0EB.2000808@ripe.net> To: Robert Kisteleki X-Mailer: Apple Mail (2.1081) Cc: sidr@ietf.org Subject: Re: [sidr] WG adoption of draft-achi-rpki-signed-object-00.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: Tue, 24 Aug 2010 14:54:29 -0000 --Apple-Mail-180--588178771 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support the adoption of the document and Robert's comment. I can see = the inclusion of the generic document in references section of the new = ROA draft but would also to see it in the main text. Roque. > Generally I support this too, but have a specific question: what's the = intended future relation between this would-be-draft and the existing = ROA draft? I mean, once we have a template, we should use that, even for = the ROAs, right? >=20 > Robert >=20 >=20 > On 2010.08.23. 16:47, Sandra Murphy wrote: >> The working group chairs have received a request from the authors of >> draft-achi-rpki-signed-object-00.txt that the working group adopt = this >> internet draft as a work item. >>=20 >> This is the draft to which Matt Lepinski alluded in his message of 20 = Aug >> 2010. As he notes, this draft is an extract of the common language = from the >> ROA format and manifest documents that has to do with the CMS = encapsulation >> for signed objects. >>=20 >> Note that the draft from which the language was extracted are already >> working group work items. The work item represented by this new draft = is the >> creation of an extract and a generic description. >>=20 >> The draft is available at >> http://tools.ietf.org/html/draft-achi-rpki-signed-object-00 >>=20 >> As always in a call for adoption: >>=20 >> Recall that active support for adoption is necessary for the wg = chairs to >> judge acceptance as a working group work item, so silence works = against >> adoption. The wg chairs also want to know who would be willing to = work on >> the draft. >>=20 >> Please respond to the list, giving your recommendation for or against >> adoption of the draft as a wg work item. >>=20 >> Because of the special circumstances of this draft, the call for = adoption >> will be shorter than usual - 10 days, ending 1 Sept 2010. >>=20 >> --Sandy, speaking as wg chair >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-180--588178771 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgyNDE0 NTQ1OVowIwYJKoZIhvcNAQkEMRYEFE2hUqrHp6/GT9ilaanZCRaiPFUIMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBAL5e29qXEOAKL0SrpBOi4LgKaVgZayciJLxZEXRHnfrymatOfB+F cL2P4XHHKqmxYzyldXLiMUr4dEqRQt1oRybEQsRr+26LAfEYFIpc++tf5DyOYogoYsYVyMuOubR3 B3hZKsK/WPBHn4IRiQ9EDj/2UybfRmzEbfriSbq/qaiBBk7AVAx4DPxdDV2i01/ALgQ+WKSqgQZ0 Ce2cwX5G0dK+9oyyOXK5S66dCA87VVK2HtNs2Tb+ka8mozUawoLAOQKQNN8tw2AP40v1Yze4CnYo 3H0MTtP2M2wP3646db3PI1rLAlMiCMYs2vxyEqipq0CJzMJJXov9g6Qr6zpJO6wAAAAAAAA= --Apple-Mail-180--588178771-- From Sandra.Murphy@cobham.com Wed Aug 25 00:31:57 2010 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 699743A6948 for ; Wed, 25 Aug 2010 00:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.155 X-Spam-Level: X-Spam-Status: No, score=-101.155 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X32bFg5hnYgi for ; Wed, 25 Aug 2010 00:31:55 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 05B803A685A for ; Wed, 25 Aug 2010 00:31:54 -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 o7P7WRMp014987 for ; Wed, 25 Aug 2010 02:32:27 -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 o7P7WRCK015068 for ; Wed, 25 Aug 2010 02:32:28 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([10.71.0.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 03:32:26 -0400 Date: Wed, 25 Aug 2010 03:32:26 -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: 25 Aug 2010 07:32:26.0802 (UTC) FILETIME=[AAAC4120:01CB4427] Subject: [sidr] Draft minutes from IETF78 Maastricht 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, 25 Aug 2010 07:31:57 -0000 Here are the draft minutes from IETF78 in Maastricht. Thanks to Vesna Manojlovic for volunteering to produce the minutes. Please send corrections, comments, additions, etc., to the list. Final minutes are due 15 Sept. These minutes have been uploaded to the IETF web site. --Sandy Secure Inter-Domain Routing WG (sidr) 78th IETF, Maastricht WEDNESDAY, July 28, 2010 1300-1530 Afternoon Session I Auditorium 2 ===================================================== CHAIR(s): Sandra Murphy Chris Morrow (audio recording available) AGENDA: 1) Administrivia - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html - WG Resources: http://tools.ietf.org/wg/sidr/ - Minute taker: Vesna Manojlovic - Jabber Scribe: Warren Kumari - Blue Sheets - Agenda Bashing Last Call status (slide #5) New WG documents (slide #6) 2) Requested Discussion Topics a) Removing TLS from the Provisioning Protocol Rob Austein http://www.ietf.org/proceedings/78/slides/sidr-0.pdf TLS was added to "up-down protocol" specification. TLS would theoretically protect from Replay Attack (example). Easier Replay protection; CMS timestamps, serial numbers, CMS introduces another problem, with MitM. Gregory: reboot. There are details that need to be worked out. A: Serial number Robert K.: if the MitM consistently keeps dropping messages, that is DoS. Jabber: Mike Hammond: if you include in your message which time-stampt you are obsoleting, that solves it. A: Gaps in the sequence, clock is not good enough. Speaker: We do not currently have with TLS protection against MitM. It could be a good additional requirement, but we would not lose it if we drop TLS. b) Alternative to the Trust Anchor Format Samuel Weiler http://www.ietf.org/proceedings/78/slides/sidr-11.pdf draft-weiler-sidr-trust-anchor-format Randy Bush: I disagree, we often have opportunities to simplify the drafts. I suggest we do not pass on this one. Robert: I prefer this one. Steve Kent: 1) it tries to re-define trust anchors, no need. 3779 tells you. This is the alternative. Q: What do you call it? Mechanism to verify the ... (?!) "something different". If this is going to become an Equivalent alternative, I've already suggested some changes in the comments to the list... Sandy: So, I hear there are some wording issues, no significant objection? A: If you add Second level, and the CRL. Randy: I would stress "explicit requirements". Rob Austin: I support it. A question to Steve: level of indirection, two level approach is a MUST? Does the WG agree to it being a MUST, or a SHOULD? I seem to recall the list supports the SHOULD. Why MUST? Steve Kent: Mandating good security practices. Sandy: I'll put the question to the mailing list. 3) Key Rollover (a) Key Rollover at RIPE NCC Presenter: Tim Bruijnzeels http://www.ietf.org/proceedings/78/slides/sidr-1.pdf Roque: Is deletion also manual, or the batch process? A: The start is manual, the rest is automated. I'm happy to do it either way. Rob Austin: I understood that all the algorithms are the same. Differences: no waiting period (?!) [staging period?] A: We go straight to the publication. (b) Key Rollover Presenter: Steve Kent http://www.ietf.org/proceedings/78/slides/sidr-7.pdf http://tools.ietf.org/id/draft-huston-sidr-aao-profile-0-keyroll-00.txt http://tools.ietf.org/id/draft-huston-sidr-repos-struct-02.txt Geoff: Step 5 happens after the staging period, not during. Geoff: "short" period means Minutes, not hours. This is the new document, so it needs review. Rob: all the implementations are doing more-less this. Comment: Lock around rsync will be .. pain in the but. I am not sure if the staging is necessary at all. Steve: We disagree. Let me explain why... Rob: OK, I have less problem with that. Rob: Do we really need to have the waiting period and locking so many things out? Geoff: The reason for suspension is to generate the clean overwrite. Sandy: It would be useful for this to happen as the conversation on the list. 4) Algorithm Migration Presenter: Roque Gagliano http://www.ietf.org/proceedings/78/slides/sidr-2.pdf Requested by Security AD. Summary: 3 questions: 1) Do we want to support only top-down algorithm transitions? 2) Do we want to support multiple signatures in CMS objects? 3) Any validation issue...? Robert: No, No, and "as long as there is *one* ROA that validates, you should accept" Paul Hofman: 1) No "top down". It will get in the way... Argue towards the "laisser faire". Rob: 1) I would like to understand it as "the Top-down is the minimum ..." (what?!) relying party is only 2) I am not sure it is worth going through all the trouble... I could live with the (...??) Steve Kent: You can not stop using the OLD algorithm, until the "end of life" / twilight. That is why the top down makes lots of sense. Geoff: I suspect that the transition means the relying party using "current" and "new" Sandy: this validates Steve's argumentation. 6) Updated Drafts (a) Certificate Policy Certificate Policy (CP) for the Resource PKI (RPKI) http://tools.ietf.org/html/draft-ietf-sidr-cp-09 Presenter: Karen Seo http://www.ietf.org/proceedings/78/slides/sidr-6.pdf (b) RPSL Signatures Securing RPSL Objects with RPKI Signatures http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-03 Presenter: Robert Kisteleki http://www.ietf.org/proceedings/78/slides/sidr-5.pdf (c) Use Cases Use Cases and interpretation of RPKI objects for issuers and relying parties http://tools.ietf.org/html/draft-ietf-sidr-usecases-00 Presenter: Sriram Kotikalapudi http://www.ietf.org/proceedings/78/slides/sidr-3.pdf 7) New Drafts (a) Publication Protocol A Publication Protocol for the Resource Public Key Infrastructure (RPKI) http://tools.ietf.org/html/draft-weiler-sidr-publication-00 Presenter: Sam Weiler http://www.ietf.org/proceedings/78/slides/sidr-12.pdf Are we ready to adopt this to the work item? Sandy: Will send a question to the mailing list. 8) New Topic (a) AS_SET, Aggregator Stats and Implications for the {Prefix, Origin} Validation Algorithm Presenter: Sriram Kotikalapudi http://www.ietf.org/proceedings/78/slides/sidr-4.pdf Q: Closest to the origin? A: The most recent AS is the extreme left, origin AS is the extreme right. Almost in all cases, the first AS after the AS_SET is the origin AS, therefore the Recommendation - disregard the aggregator! John Scutter, Juniper networks: OK ?: Can not treat the agreggator like that, .... 4-bite AS purposes: additional consistency checks need to be performed. AS SET is optional Rudiger: I am not sure if the new attack type is any different then any other attack that can be performed by such attacker. Private ASN should not show up. BGP specs need clean-up. Gregory, France Telecom: Conclusions based on current statistics. If we base the algorithm on this, add recommendation to do have the correct ASN behind the aggregator. John Scudder: It does make sense from the PoV of how the AS path is constructed. 5) Use of RPKI in Routers (a) RPKI Use in Routers The RPKI/Router Protocol draft-ymbk-rpki-rtr-protocol-06.txt http://tools.ietf.org/html/draft-ymbk-rpki-rtr-protocol-06 Presenter: Randy Bush http://www.ietf.org/proceedings/78/slides/sidr-8.pdf Q: Alexis: should it also reevaluate discarded prefixes? A: (?) Q: What happens when there is no other cache? A: Start paddling! (b) BGP Prefix Origin Validation draft-pmohapat-sidr-pfx-validate-07 http://tools.ietf.org/id/draft-pmohapat-sidr-pfx-validate-07.txt Presenter: Randy Bush http://www.ietf.org/proceedings/78/slides/sidr-9.pdf Solution: allow the operator to test the validity, and set local policy Q: Does something prevents the router to rewrite the policy? A: (?) John: you want all the routers to follow the same policies Jeff: advertise best-external-always Q: Alexei: if all 3 have different state... A: The reason for this is: Incremental deployment. When I add my first router (with RPKI), I can add this to my existing policy. Dani: If your different routers can have different cashes... then you have bigger problem. Rob Austin: Global distributed DB. They will not have the same view nor consistent state. 6) Updated Drafts Validation Signaling BGP Prefix Origin Validation State Extended Community http://tools.ietf.org/id/draft-pmohapat-sidr-origin-validation-signaling-00.txt Presenter: Keyur Patel http://www.ietf.org/proceedings/78/slides/sidr-13.pptx Defining the new extended community. Randy: Let's have this as the WG draft, so I can disagree with it. Alexis: I don't see why do we need 3 new community space for 3 new communities. Nor global well knows communities. You cna just choose A: It's just one, with 3 bits. Anyway, it is in my opinion, polluting the number space. John Scudder: I mostly agree, but with regular communities there is no transitivity bit. Dani: I support this. Randy: I think it could be useful for diagnostics. Final comment by the Chair: NRO has the deadline at 1.1.2011 to start operations with RPKI. It would be good if our documents be out of the Last Call. Before the Beijging meeting. Please comment on drafts! (next meeting - please send the slides before the day of the session). From Sandra.Murphy@cobham.com Wed Aug 25 01:02:47 2010 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 E5E363A6862 for ; Wed, 25 Aug 2010 01:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 4+y5PcR4XpQA for ; Wed, 25 Aug 2010 01:02:46 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 76B343A67F0 for ; Wed, 25 Aug 2010 01:02:46 -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 o7P83Irh015075; Wed, 25 Aug 2010 03:03:19 -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 o7P83IE5015393; Wed, 25 Aug 2010 03:03:18 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([10.71.0.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 04:03:18 -0400 Date: Wed, 25 Aug 2010 04:03:17 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Robert Kisteleki In-Reply-To: <4C73D0EB.2000808@ripe.net> Message-ID: References: <4C73D0EB.2000808@ripe.net> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Aug 2010 08:03:18.0114 (UTC) FILETIME=[FA240C20:01CB442B] Cc: sidr@ietf.org Subject: Re: [sidr] WG adoption of draft-achi-rpki-signed-object-00.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: Wed, 25 Aug 2010 08:02:48 -0000 I think Matt's message to the list of 20 Aug 2010 included a revised version of the roa format that would make use of the generic signed object draft. If the generic signed object draft is adopted by the wg, then the roa format draft authors will have the opportunity to change the roa format draft in accordance with wg consensus. --Sandy On Tue, 24 Aug 2010, Robert Kisteleki wrote: > Generally I support this too, but have a specific question: what's the > intended future relation between this would-be-draft and the existing ROA > draft? I mean, once we have a template, we should use that, even for the > ROAs, right? > > Robert > > > On 2010.08.23. 16:47, Sandra Murphy wrote: >> The working group chairs have received a request from the authors of >> draft-achi-rpki-signed-object-00.txt that the working group adopt this >> internet draft as a work item. >> >> This is the draft to which Matt Lepinski alluded in his message of 20 Aug >> 2010. As he notes, this draft is an extract of the common language from the >> ROA format and manifest documents that has to do with the CMS encapsulation >> for signed objects. >> >> Note that the draft from which the language was extracted are already >> working group work items. The work item represented by this new draft is >> the >> creation of an extract and a generic description. >> >> The draft is available at >> http://tools.ietf.org/html/draft-achi-rpki-signed-object-00 >> >> As always in a call for adoption: >> >> Recall that active support for adoption is necessary for the wg chairs to >> judge acceptance as a working group work item, so silence works against >> adoption. The wg chairs also want to know who would be willing to work on >> the draft. >> >> Please respond to the list, giving your recommendation for or against >> adoption of the draft as a wg work item. >> >> Because of the special circumstances of this draft, the call for adoption >> will be shorter than usual - 10 days, ending 1 Sept 2010. >> >> --Sandy, speaking as wg chair >> >> >> _______________________________________________ >> 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 Sandra.Murphy@cobham.com Wed Aug 25 01:18:02 2010 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 32A9A3A6AA8 for ; Wed, 25 Aug 2010 01:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 nYjogrnYI0Nb for ; Wed, 25 Aug 2010 01:18:01 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 344123A6AA7 for ; Wed, 25 Aug 2010 01:18:01 -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 o7P8IXKc015110 for ; Wed, 25 Aug 2010 03:18:33 -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 o7P8IYjl015554 for ; Wed, 25 Aug 2010 03:18:34 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([10.71.0.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 04:18:33 -0400 Date: Wed, 25 Aug 2010 04:18:32 -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: 25 Aug 2010 08:18:33.0543 (UTC) FILETIME=[1BC76D70:01CB442E] Subject: [sidr] adopting alternate trust format in draft-ietf-sidr-ta-04 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, 25 Aug 2010 08:18:02 -0000 Draft draft-weiler-sidr-trust-anchor-format-00.txt suggests an alternate trust anchor representation format from that proposed in draft-ietf-sidr-ta-04. This alternate format was discussed in the sidr meeting in IETF78 in Maastricht. I am asking for comment on the list as to whether there is wg consensus that draft-ietf-sidr-ta-04 should use the alternative format. Please respond so that the authors can represent wg consensus in the draft. The call for consensus will end Sept 8. --Sandy From Sandra.Murphy@cobham.com Wed Aug 25 01:18:13 2010 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 514043A6AB5 for ; Wed, 25 Aug 2010 01:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 FkCJO4yQn3hs for ; Wed, 25 Aug 2010 01:18:12 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 59D403A67F0 for ; Wed, 25 Aug 2010 01:18:12 -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 o7P8IjYW015114 for ; Wed, 25 Aug 2010 03:18: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 o7P8IjVG015560 for ; Wed, 25 Aug 2010 03:18:45 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([10.71.0.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 04:18:44 -0400 Date: Wed, 25 Aug 2010 04:18: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: 25 Aug 2010 08:18:44.0830 (UTC) FILETIME=[2281AFE0:01CB442E] Subject: [sidr] removing TLS from the provisioning protocol 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, 25 Aug 2010 08:18:13 -0000 We had a discussion in April on the list regarding removing TLS from the provisioning protocol. Rob Austein presented his views on the issue at the sidr meeting at the IETF78 in Maastricht. I am calling for wg consensus on the question. Should the authors of draft-ietf-sidr-rescerts-provisioning-06 revise that draft to remove TLS from the protocol? Please respond to the list by 8 Sept, so the authors can represent wg consensus in the draft. --Sandy From Sandra.Murphy@cobham.com Wed Aug 25 01:22:45 2010 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 13F623A6AA0 for ; Wed, 25 Aug 2010 01:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 iZWnw-ysz1xg for ; Wed, 25 Aug 2010 01:22:43 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 0A3113A67F0 for ; Wed, 25 Aug 2010 01:22:42 -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 o7P8NFet015149 for ; Wed, 25 Aug 2010 03:23:15 -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 o7P8NGLx015612 for ; Wed, 25 Aug 2010 03:23:16 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([10.71.0.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 04:23:15 -0400 Date: Wed, 25 Aug 2010 04:23:14 -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: 25 Aug 2010 08:23:15.0438 (UTC) FILETIME=[C3CD30E0:01CB442E] Subject: [sidr] WG adoption of draft-huston-sidr-keyroll-00.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: Wed, 25 Aug 2010 08:22:45 -0000 Geoff Huston has requested that the working group adopt the draft "CA Key Rollover in the RPKI" draft-huston-sidr-keyroll-00.txt. This draft was announced on July 26. This wg chair apologizes to the authors for the delay in making the requested wg call for adoption. The draft is available at http://www.ietf.org/id/draft-huston-sidr-keyroll-00.txt http://tools.ietf.org/html/draft-huston-sidr-keyroll-00 The draft was presented at the sidr meeting in IETF78 in Maastricht, NL. The slides are available at http://www.ietf.org/proceedings/78/slides/sidr-7.pdf. Recall that active support for adoption is necessary for the wg chairs to judge acceptance as a working group work item, so silence works against adoption. The wg chairs also want to know who would be willing to work on the draft. Please respond to the list, giving your recommendation for or against adoption of the draft as a wg work item as well as your intention to work on the draft if adopted. The call for adoption will end in two weeks on 8 Sep 2010. --Sandy, speaking as wg chair From Sandra.Murphy@cobham.com Wed Aug 25 01:23:21 2010 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 462383A6ABB for ; Wed, 25 Aug 2010 01:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 prujPYuIUBiJ for ; Wed, 25 Aug 2010 01:23:09 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 7CD433A6ABE for ; Wed, 25 Aug 2010 01:23:06 -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 o7P8MkOU015145; Wed, 25 Aug 2010 03:22:47 -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 o7P8MkFE015606; Wed, 25 Aug 2010 03:22:46 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([10.71.0.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 04:22:45 -0400 Date: Wed, 25 Aug 2010 04:22:42 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Aug 2010 08:22:45.0886 (UTC) FILETIME=[B22FE9E0:01CB442E] Cc: Adrian Farrel , "sidr@ietf.org wg" Subject: Re: [sidr] WG adoption 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, 25 Aug 2010 08:23:21 -0000 Geoff is correct, I did miss making the requested wg call for adoption. --Sandy, speaking as wg chair On Tue, 24 Aug 2010, Geoff Huston wrote: > The Working Group chairs have also received a request from the authors of draft-huston-sidr-keyroll-00.txt on the 26th July that the working group adopt this internet draft as a work item, and a followup in support of this request from a working group member on the 4th August. > > Would the WG chairs please act on this earlier request, or kindly indicate the exact nature of procedural errors in the earlier request so that the authors may redress them to the extent possible? > > > > On 24/08/2010, at 12:47 AM, Sandra Murphy wrote: > >> The working group chairs have received a request from the authors of draft-achi-rpki-signed-object-00.txt that the working group adopt this internet draft as a work item. >> >> This is the draft to which Matt Lepinski alluded in his message of 20 Aug 2010. As he notes, this draft is an extract of the common language from the ROA format and manifest documents that has to do with the CMS encapsulation for signed objects. >> >> Note that the draft from which the language was extracted are already working group work items. The work item represented by this new draft is the creation of an extract and a generic description. >> >> The draft is available at http://tools.ietf.org/html/draft-achi-rpki-signed-object-00 >> >> As always in a call for adoption: >> >> Recall that active support for adoption is necessary for the wg chairs to >> judge acceptance as a working group work item, so silence works against >> adoption. The wg chairs also want to know who would be willing to work on >> the draft. >> >> Please respond to the list, giving your recommendation for or against >> adoption of the draft as a wg work item. >> >> Because of the special circumstances of this draft, the call for adoption will be shorter than usual - 10 days, ending 1 Sept 2010. >> >> --Sandy, speaking as wg chair >> >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > > > From Sandra.Murphy@cobham.com Wed Aug 25 01:23:22 2010 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 736E33A6AC7 for ; Wed, 25 Aug 2010 01:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 kTs8sYISVOaw for ; Wed, 25 Aug 2010 01:23:17 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 7FFEB3A6AC1 for ; Wed, 25 Aug 2010 01:23:06 -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 o7P8NaxY015153 for ; Wed, 25 Aug 2010 03:23:36 -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 o7P8NaZQ015627 for ; Wed, 25 Aug 2010 03:23:37 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([10.71.0.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 04:23:36 -0400 Date: Wed, 25 Aug 2010 04:23:35 -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: 25 Aug 2010 08:23:36.0177 (UTC) FILETIME=[D029B610:01CB442E] Subject: [sidr] WG LC for draft-ietf-sidr-cp-10.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: Wed, 25 Aug 2010 08:23:22 -0000 The authors of "Certificate Policy (CP) for the Resource PKI (RPKI)" have requested a working group last call on this draft. The draft is available at http://tools.ietf.org/html/draft-ietf-sidr-cp-10. The authors indicate that the following changes have been made: 1. Added 147 RFC 2119 words 2. Changed "2.1. Repositories" to require conformance to the spec "A Profile for Resource Certificate Repository Structure" 3. Changed "3.2.4. Non-verified subscriber information" From: No non-verified subscriber data is included in certificates issued under this certificate policy except for SIA/AIA extensions. To: No non-verified subscriber data is included in certificates issued under this certificate policy except for SIA extensions. 4. Changed Section "4.7. Certificate re-key" to require conformance to the spec for "CA Key Rollover in the RPKI" This document has been through last call once before, which ordinarily would mean that this review would verify that previous last call comments had been adequately dealt with. However, the number of changes made since the last wglc indicate a full review would be wise, particularly the 2119 language. Please review the document and send comments to the list, and indicate whether you believe that this document is ready to leave the wg. The wglc will end on 10 Sept. --Sandy, speaking as wg chair From Sandra.Murphy@cobham.com Wed Aug 25 01:24:27 2010 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 AF4D63A6AA8 for ; Wed, 25 Aug 2010 01:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 ZyGOCLzL4k0b for ; Wed, 25 Aug 2010 01:24:19 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 6A8443A67F0 for ; Wed, 25 Aug 2010 01:24:19 -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 o7P8OpaE015159; Wed, 25 Aug 2010 03:24:51 -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 o7P8OqHx015647; Wed, 25 Aug 2010 03:24:52 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([10.71.0.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 04:24:51 -0400 Date: Wed, 25 Aug 2010 04:24:50 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Robert Kisteleki In-Reply-To: Message-ID: References: <4C73D0EB.2000808@ripe.net> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Aug 2010 08:24:51.0659 (UTC) FILETIME=[FD2759B0:01CB442E] Cc: sidr@ietf.org Subject: Re: [sidr] WG adoption of draft-achi-rpki-signed-object-00.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: Wed, 25 Aug 2010 08:24:27 -0000 Forgot to add the obligatory coda... On Wed, 25 Aug 2010, Sandra Murphy wrote: > I think Matt's message to the list of 20 Aug 2010 included a revised version > of the roa format that would make use of the generic signed object draft. > > If the generic signed object draft is adopted by the wg, then the roa format > draft authors will have the opportunity to change the roa format draft in > accordance with wg consensus. > > --Sandy --Sandy, speaking as wg chair > > > > On Tue, 24 Aug 2010, Robert Kisteleki wrote: > >> Generally I support this too, but have a specific question: what's the >> intended future relation between this would-be-draft and the existing ROA >> draft? I mean, once we have a template, we should use that, even for the >> ROAs, right? >> >> Robert >> >> >> On 2010.08.23. 16:47, Sandra Murphy wrote: >>> The working group chairs have received a request from the authors of >>> draft-achi-rpki-signed-object-00.txt that the working group adopt this >>> internet draft as a work item. >>> >>> This is the draft to which Matt Lepinski alluded in his message of 20 Aug >>> 2010. As he notes, this draft is an extract of the common language from >>> the >>> ROA format and manifest documents that has to do with the CMS >>> encapsulation >>> for signed objects. >>> >>> Note that the draft from which the language was extracted are already >>> working group work items. The work item represented by this new draft is >>> the >>> creation of an extract and a generic description. >>> >>> The draft is available at >>> http://tools.ietf.org/html/draft-achi-rpki-signed-object-00 >>> >>> As always in a call for adoption: >>> >>> Recall that active support for adoption is necessary for the wg chairs to >>> judge acceptance as a working group work item, so silence works against >>> adoption. The wg chairs also want to know who would be willing to work on >>> the draft. >>> >>> Please respond to the list, giving your recommendation for or against >>> adoption of the draft as a wg work item. >>> >>> Because of the special circumstances of this draft, the call for adoption >>> will be shorter than usual - 10 days, ending 1 Sept 2010. >>> >>> --Sandy, speaking as wg chair >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Wed Aug 25 01:25:00 2010 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 AAF4E3A6AA7 for ; Wed, 25 Aug 2010 01:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 688n9OffR32J for ; Wed, 25 Aug 2010 01:24:58 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 757603A6A96 for ; Wed, 25 Aug 2010 01:24: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 o7P8PVZb015167 for ; Wed, 25 Aug 2010 03:25: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 o7P8PVYs015683 for ; Wed, 25 Aug 2010 03:25:31 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([10.71.0.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 04:25:31 -0400 Date: Wed, 25 Aug 2010 04:25:30 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Aug 2010 08:25:31.0056 (UTC) FILETIME=[14A2DB00:01CB442F] Subject: Re: [sidr] adopting alternate trust format in draft-ietf-sidr-ta-04 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, 25 Aug 2010 08:25:00 -0000 Forgot to add the obligatory coda: On Wed, 25 Aug 2010, Sandra Murphy wrote: > Draft draft-weiler-sidr-trust-anchor-format-00.txt suggests an alternate > trust anchor representation format from that proposed in > draft-ietf-sidr-ta-04. This alternate format was discussed in the sidr > meeting in IETF78 in Maastricht. > > I am asking for comment on the list as to whether there is wg consensus that > draft-ietf-sidr-ta-04 should use the alternative format. > > Please respond so that the authors can represent wg consensus in the draft. > The call for consensus will end Sept 8. > > --Sandy --Sandy, speaking as wg chair > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Wed Aug 25 01:25:34 2010 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 0976B3A6918 for ; Wed, 25 Aug 2010 01:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 7Uzg5rotjFrq for ; Wed, 25 Aug 2010 01:25:32 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 6F54E3A6AA8 for ; Wed, 25 Aug 2010 01:25:31 -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 o7P8Q4ni015173 for ; Wed, 25 Aug 2010 03: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 o7P8Q4Ib015690 for ; Wed, 25 Aug 2010 03:26:04 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([10.71.0.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 04:26:03 -0400 Date: Wed, 25 Aug 2010 04:26:03 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Aug 2010 08:26:04.0045 (UTC) FILETIME=[284C93D0:01CB442F] Subject: Re: [sidr] removing TLS from the provisioning protocol 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, 25 Aug 2010 08:25:34 -0000 Forgot to add the obligatory coda: On Wed, 25 Aug 2010, Sandra Murphy wrote: > We had a discussion in April on the list regarding removing TLS from the > provisioning protocol. Rob Austein presented his views on the issue at the > sidr meeting at the IETF78 in Maastricht. > > I am calling for wg consensus on the question. Should the authors of > draft-ietf-sidr-rescerts-provisioning-06 revise that draft to remove TLS from > the protocol? > > Please respond to the list by 8 Sept, so the authors can represent wg > consensus in the draft. > > --Sandy --Sandy, speaking as wg chair > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Wed Aug 25 01:55:41 2010 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 EF8C43A67F3 for ; Wed, 25 Aug 2010 01:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 LombgMnisxqw for ; Wed, 25 Aug 2010 01:55:34 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 255583A67F0 for ; Wed, 25 Aug 2010 01:55:33 -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 o7P8u6eD015259 for ; Wed, 25 Aug 2010 03:56: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 o7P8u70J016355 for ; Wed, 25 Aug 2010 03:56:07 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([10.71.0.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 04:56:06 -0400 Date: Wed, 25 Aug 2010 04:56:05 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Aug 2010 08:56:06.0296 (UTC) FILETIME=[5A864180:01CB4433] Subject: Re: [sidr] Draft minutes from IETF78 Maastricht 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, 25 Aug 2010 08:55:41 -0000 And this one, too: On Wed, 25 Aug 2010, Sandra Murphy wrote: > Here are the draft minutes from IETF78 in Maastricht. Thanks to Vesna > Manojlovic for volunteering to produce the minutes. > > Please send corrections, comments, additions, etc., to the list. Final > minutes are due 15 Sept. > > These minutes have been uploaded to the IETF web site. > > --Sandy --Sandy, speaking as wg chair > > Secure Inter-Domain Routing WG (sidr) > 78th IETF, Maastricht WEDNESDAY, July 28, 2010 1300-1530 Afternoon Session I > Auditorium 2 > ===================================================== > CHAIR(s): Sandra Murphy > Chris Morrow > (audio recording available) > AGENDA: > 1) Administrivia > - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html > - WG Resources: http://tools.ietf.org/wg/sidr/ > - Minute taker: Vesna Manojlovic > - Jabber Scribe: Warren Kumari > - Blue Sheets > - Agenda Bashing > > Last Call status (slide #5) > New WG documents (slide #6) > > > 2) Requested Discussion Topics > > a) Removing TLS from the Provisioning Protocol Rob Austein > http://www.ietf.org/proceedings/78/slides/sidr-0.pdf > > TLS was added to "up-down protocol" specification. > TLS would theoretically protect from Replay Attack (example). > Easier Replay protection; CMS timestamps, serial numbers, > CMS introduces another problem, with MitM. > > Gregory: reboot. > There are details that need to be worked out. > A: Serial number > > Robert K.: if the MitM consistently keeps dropping messages, that is DoS. > > Jabber: Mike Hammond: if you include in your message which time-stampt you > are obsoleting, that solves it. > A: Gaps in the sequence, clock is not good enough. > > Speaker: We do not currently have with TLS protection against MitM. It could > be a good additional requirement, but we would not lose it if we drop TLS. > > b) Alternative to the Trust Anchor Format Samuel Weiler > http://www.ietf.org/proceedings/78/slides/sidr-11.pdf > draft-weiler-sidr-trust-anchor-format > > Randy Bush: I disagree, we often have opportunities to simplify the drafts. I > suggest we do not pass on this one. > > Robert: I prefer this one. > Steve Kent: 1) it tries to re-define trust anchors, no need. > 3779 tells you. > This is the alternative. > Q: What do you call it? > Mechanism to verify the ... (?!) > "something different". > If this is going to become an Equivalent alternative, I've already suggested > some changes in the comments to the list... > > Sandy: So, I hear there are some wording issues, no significant objection? > > A: If you add Second level, and the CRL. > > Randy: I would stress "explicit requirements". > > Rob Austin: I support it. > A question to Steve: level of indirection, two level approach is a MUST? > Does the WG agree to it being a MUST, or a SHOULD? > I seem to recall the list supports the SHOULD. Why MUST? > Steve Kent: Mandating good security practices. > Sandy: I'll put the question to the mailing list. > > 3) Key Rollover > (a) Key Rollover at RIPE NCC > Presenter: Tim Bruijnzeels > http://www.ietf.org/proceedings/78/slides/sidr-1.pdf > > Roque: Is deletion also manual, or the batch process? > A: The start is manual, the rest is automated. I'm happy to do it either way. > > Rob Austin: I understood that all the algorithms are the same. > Differences: no waiting period (?!) [staging period?] > A: We go straight to the publication. > > (b) Key Rollover > Presenter: Steve Kent > http://www.ietf.org/proceedings/78/slides/sidr-7.pdf > http://tools.ietf.org/id/draft-huston-sidr-aao-profile-0-keyroll-00.txt > http://tools.ietf.org/id/draft-huston-sidr-repos-struct-02.txt > > Geoff: Step 5 happens after the staging period, not during. > Geoff: "short" period means Minutes, not hours. > > This is the new document, so it needs review. > > Rob: all the implementations are doing more-less this. > Comment: Lock around rsync will be .. pain in the but. > I am not sure if the staging is necessary at all. > > Steve: We disagree. Let me explain why... > Rob: OK, I have less problem with that. > > Rob: Do we really need to have the waiting period and locking so many things > out? > Geoff: The reason for suspension is to generate the clean overwrite. > > Sandy: It would be useful for this to happen as the conversation on the list. > > 4) Algorithm Migration > Presenter: Roque Gagliano > http://www.ietf.org/proceedings/78/slides/sidr-2.pdf > > Requested by Security AD. > > Summary: 3 questions: > 1) Do we want to support only top-down algorithm transitions? > 2) Do we want to support multiple signatures in CMS objects? > 3) Any validation issue...? > > Robert: No, No, and "as long as there is *one* ROA that validates, you should > accept" > > Paul Hofman: 1) No "top down". It will get in the way... > Argue towards the "laisser faire". > > Rob: > 1) I would like to understand it as "the Top-down is the minimum ..." > (what?!) > relying party is only > 2) I am not sure it is worth going through all the trouble... > I could live with the (...??) > > Steve Kent: You can not stop using the OLD algorithm, until the "end of life" > / twilight. > That is why the top down makes lots of sense. > > Geoff: I suspect that the transition means the relying party using "current" > and "new" > Sandy: this validates Steve's argumentation. > > 6) Updated Drafts > (a) Certificate Policy > Certificate Policy (CP) for the Resource PKI (RPKI) > http://tools.ietf.org/html/draft-ietf-sidr-cp-09 > Presenter: Karen Seo > > http://www.ietf.org/proceedings/78/slides/sidr-6.pdf > > (b) RPSL Signatures > Securing RPSL Objects with RPKI Signatures > http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-03 > Presenter: Robert Kisteleki > > http://www.ietf.org/proceedings/78/slides/sidr-5.pdf > > > (c) Use Cases > Use Cases and interpretation of RPKI objects for issuers and relying > parties > http://tools.ietf.org/html/draft-ietf-sidr-usecases-00 > Presenter: Sriram Kotikalapudi > > http://www.ietf.org/proceedings/78/slides/sidr-3.pdf > > 7) New Drafts > (a) Publication Protocol > A Publication Protocol for the Resource Public Key Infrastructure > (RPKI) > http://tools.ietf.org/html/draft-weiler-sidr-publication-00 > > Presenter: Sam Weiler > > http://www.ietf.org/proceedings/78/slides/sidr-12.pdf > > Are we ready to adopt this to the work item? > > Sandy: Will send a question to the mailing list. > > > 8) New Topic > > (a) AS_SET, Aggregator Stats and Implications for the {Prefix, Origin} > Validation Algorithm > > Presenter: Sriram Kotikalapudi > > http://www.ietf.org/proceedings/78/slides/sidr-4.pdf > > Q: Closest to the origin? > A: The most recent AS is the extreme left, origin AS is the extreme right. > > Almost in all cases, the first AS after the AS_SET is the origin AS, > therefore the Recommendation - disregard the aggregator! > > John Scutter, Juniper networks: OK > > ?: Can not treat the agreggator like that, .... > > 4-bite AS purposes: additional consistency checks need to be performed. > > AS SET is optional > > Rudiger: I am not sure if the new attack type is any different then any other > attack that can be performed by such attacker. > > Private ASN should not show up. BGP specs need clean-up. > > Gregory, France Telecom: Conclusions based on current statistics. If we base > the algorithm on this, add recommendation to do have the correct ASN behind > the aggregator. > > John Scudder: It does make sense from the PoV of how the AS path is > constructed. > > 5) Use of RPKI in Routers > > (a) RPKI Use in Routers > The RPKI/Router Protocol > draft-ymbk-rpki-rtr-protocol-06.txt > http://tools.ietf.org/html/draft-ymbk-rpki-rtr-protocol-06 > Presenter: Randy Bush > > http://www.ietf.org/proceedings/78/slides/sidr-8.pdf > > Q: Alexis: should it also reevaluate discarded prefixes? > A: (?) > > Q: What happens when there is no other cache? > A: Start paddling! > > (b) BGP Prefix Origin Validation > draft-pmohapat-sidr-pfx-validate-07 > http://tools.ietf.org/id/draft-pmohapat-sidr-pfx-validate-07.txt > Presenter: Randy Bush > > http://www.ietf.org/proceedings/78/slides/sidr-9.pdf > > Solution: allow the operator to test the validity, and set local policy > > Q: Does something prevents the router to rewrite the policy? > A: (?) > > John: you want all the routers to follow the same policies > Jeff: advertise best-external-always > > Q: Alexei: if all 3 have different state... > A: The reason for this is: Incremental deployment. When I add my first router > (with RPKI), I can add this to my existing policy. > > Dani: If your different routers can have different cashes... then you have > bigger problem. > > Rob Austin: Global distributed DB. They will not have the same view nor > consistent state. > > 6) Updated Drafts > > Validation Signaling > BGP Prefix Origin Validation State Extended Community > > http://tools.ietf.org/id/draft-pmohapat-sidr-origin-validation-signaling-00.txt > Presenter: Keyur Patel > > http://www.ietf.org/proceedings/78/slides/sidr-13.pptx > > Defining the new extended community. > > Randy: Let's have this as the WG draft, so I can disagree with it. > > Alexis: I don't see why do we need 3 new community space for 3 new > communities. Nor global well knows communities. You cna just choose > A: It's just one, with 3 bits. > Anyway, it is in my opinion, polluting the number space. > > John Scudder: I mostly agree, but with regular communities there is no > transitivity bit. > > Dani: I support this. > > Randy: I think it could be useful for diagnostics. > > Final comment by the Chair: NRO has the deadline at 1.1.2011 to start > operations with RPKI. > It would be good if our documents be out of the Last Call. Before the > Beijging meeting. > > Please comment on drafts! > > (next meeting - please send the slides before the day of the session). > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Wed Aug 25 02:55:15 2010 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 7DF753A685E for ; Wed, 25 Aug 2010 02:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 bNt9Q1zfVBod for ; Wed, 25 Aug 2010 02:55:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 2161D3A6AAC for ; Wed, 25 Aug 2010 02:55:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoCht-000Bae-UR; Wed, 25 Aug 2010 09:55:46 +0000 Date: Wed, 25 Aug 2010 18:55:43 +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] adopting alternate trust format in draft-ietf-sidr-ta-04 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, 25 Aug 2010 09:55:15 -0000 > I am asking for comment on the list as to whether there is wg consensus > that draft-ietf-sidr-ta-04 should use the alternative format. yes, please. randy From randy@psg.com Wed Aug 25 02:55:34 2010 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 6CBF23A6AB4 for ; Wed, 25 Aug 2010 02:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 zf8LAhjoSkpB for ; Wed, 25 Aug 2010 02:55:33 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 659113A6AAB for ; Wed, 25 Aug 2010 02:55:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoCiD-000Bay-Sd; Wed, 25 Aug 2010 09:56:06 +0000 Date: Wed, 25 Aug 2010 18:56:04 +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] removing TLS from the provisioning protocol 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, 25 Aug 2010 09:55:34 -0000 > I am calling for wg consensus on the question. Should the authors of > draft-ietf-sidr-rescerts-provisioning-06 revise that draft to remove TLS > from the protocol? yes, please From robert@ripe.net Wed Aug 25 03:05:51 2010 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 0667D3A6ABB for ; Wed, 25 Aug 2010 03:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CMjkynn2gEW for ; Wed, 25 Aug 2010 03:05:49 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 10A2B3A6AAB for ; Wed, 25 Aug 2010 03:05:49 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OoCry-000291-Kc for sidr@ietf.org; Wed, 25 Aug 2010 12:06:20 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=Kistel-Mac.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OoCry-0005qY-8E for sidr@ietf.org; Wed, 25 Aug 2010 12:06:10 +0200 Message-ID: <4C74EB12.4050209@ripe.net> Date: Wed, 25 Aug 2010 12:06:10 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274faf272e421dbd620c0e577c6f38e77fd X-RIPE-Spam-Level: -- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274faf272e421dbd620c0e577c6f38e77fd Subject: Re: [sidr] adopting alternate trust format in draft-ietf-sidr-ta-04 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, 25 Aug 2010 10:05:51 -0000 I support the change. On 2010.08.25. 10:18, Sandra Murphy wrote: > Draft draft-weiler-sidr-trust-anchor-format-00.txt suggests an alternate > trust anchor representation format from that proposed in > draft-ietf-sidr-ta-04. This alternate format was discussed in the sidr > meeting in IETF78 in Maastricht. > > I am asking for comment on the list as to whether there is wg consensus that > draft-ietf-sidr-ta-04 should use the alternative format. > > Please respond so that the authors can represent wg consensus in the draft. > The call for consensus will end Sept 8. > > --Sandy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From robert@ripe.net Wed Aug 25 03:06:25 2010 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 55D963A6AB5 for ; Wed, 25 Aug 2010 03:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+q98lnZGz38 for ; Wed, 25 Aug 2010 03:06:23 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 54AE53A6ABF for ; Wed, 25 Aug 2010 03:06:23 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OoCsc-0002AD-Ry for sidr@ietf.org; Wed, 25 Aug 2010 12:06:55 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=Kistel-Mac.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OoCsc-0005tC-LP for sidr@ietf.org; Wed, 25 Aug 2010 12:06:50 +0200 Message-ID: <4C74EB3A.2070402@ripe.net> Date: Wed, 25 Aug 2010 12:06:50 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274f3e143676f0ac099f094aa324c7525e4 X-RIPE-Spam-Level: -- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274f3e143676f0ac099f094aa324c7525e4 Subject: Re: [sidr] removing TLS from the provisioning protocol 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, 25 Aug 2010 10:06:25 -0000 I support this change. Robert On 2010.08.25. 10:18, Sandra Murphy wrote: > We had a discussion in April on the list regarding removing TLS from the > provisioning protocol. Rob Austein presented his views on the issue at the > sidr meeting at the IETF78 in Maastricht. > > I am calling for wg consensus on the question. Should the authors of > draft-ietf-sidr-rescerts-provisioning-06 revise that draft to remove TLS > from the protocol? > > Please respond to the list by 8 Sept, so the authors can represent wg > consensus in the draft. > > --Sandy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From robert@ripe.net Wed Aug 25 03:06:56 2010 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 054023A6AAB for ; Wed, 25 Aug 2010 03:06:56 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuRoKdgInQie for ; Wed, 25 Aug 2010 03:06:54 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id E8EA33A6AB5 for ; Wed, 25 Aug 2010 03:06:53 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OoCt4-0002Ad-Ru for sidr@ietf.org; Wed, 25 Aug 2010 12:07:26 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=Kistel-Mac.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OoCt4-00061l-MD for sidr@ietf.org; Wed, 25 Aug 2010 12:07:18 +0200 Message-ID: <4C74EB56.8080207@ripe.net> Date: Wed, 25 Aug 2010 12:07:18 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274df3d2d61ac7cd89abb1aedbb782ea06f X-RIPE-Spam-Level: -- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274df3d2d61ac7cd89abb1aedbb782ea06f Subject: Re: [sidr] WG adoption of draft-huston-sidr-keyroll-00.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: Wed, 25 Aug 2010 10:06:56 -0000 I support this. Robert On 2010.08.25. 10:23, Sandra Murphy wrote: > Geoff Huston has requested that the working group adopt the draft "CA Key > Rollover in the RPKI" draft-huston-sidr-keyroll-00.txt. This draft was > announced on July 26. This wg chair apologizes to the authors for the delay > in making the requested wg call for adoption. > > The draft is available at > http://www.ietf.org/id/draft-huston-sidr-keyroll-00.txt > http://tools.ietf.org/html/draft-huston-sidr-keyroll-00 > > The draft was presented at the sidr meeting in IETF78 in Maastricht, NL. The > slides are available at http://www.ietf.org/proceedings/78/slides/sidr-7.pdf. > > Recall that active support for adoption is necessary for the wg chairs to > judge acceptance as a working group work item, so silence works against > adoption. The wg chairs also want to know who would be willing to work on > the draft. > > Please respond to the list, giving your recommendation for or against > adoption of the draft as a wg work item as well as your intention to work > on the draft if adopted. The call for adoption will end in two weeks on 8 > Sep 2010. > > --Sandy, speaking as wg chair > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kotikalapudi.sriram@nist.gov Wed Aug 25 07:25:36 2010 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 01E883A6A41 for ; Wed, 25 Aug 2010 07:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 fdXwv3T9-1O2 for ; Wed, 25 Aug 2010 07:25:35 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 8EE883A69EF for ; Wed, 25 Aug 2010 07:25:31 -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 o7PEPk7B029428; Wed, 25 Aug 2010 10:25:46 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 25 Aug 2010 10:25:46 -0400 From: "Sriram, Kotikalapudi" To: Sandra Murphy , "sidr@ietf.org" Date: Wed, 25 Aug 2010 10:23:39 -0400 Thread-Topic: [sidr] removing TLS from the provisioning protocol Thread-Index: ActELzAgZle2FXl4SXW9xQyS9bLzTQAMexod 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" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Subject: Re: [sidr] removing TLS from the provisioning protocol 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, 25 Aug 2010 14:25:36 -0000 > I am calling for wg consensus on the question. Should the authors of > draft-ietf-sidr-rescerts-provisioning-06 revise that draft to remove TLS from > the protocol? I support this revision. Sriram From ggm@apnic.net Wed Aug 25 15:56:30 2010 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 C90CD3A68A5 for ; Wed, 25 Aug 2010 15:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.091 X-Spam-Level: *** X-Spam-Status: No, score=3.091 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_HCC=4.295, HOST_EQ_DHCP=1.295, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqht-yhi11wt for ; Wed, 25 Aug 2010 15:56:30 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 4C8F53A689B for ; Wed, 25 Aug 2010 15:56:30 -0700 (PDT) Received: from 121.10.dhcp.conference.apricot.net (121.10.dhcp.conference.apricot.net [169.223.10.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id CF9DAD589E for ; Thu, 26 Aug 2010 08:57:01 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: George Michaelson In-Reply-To: Date: Thu, 26 Aug 2010 08:57:01 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: sidr@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [sidr] WG adoption of draft-huston-sidr-keyroll-00.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: Wed, 25 Aug 2010 22:56:30 -0000 I support adoption of this draft as a WG item. -george On 25/08/2010, at 6:23 PM, Sandra Murphy wrote: > Geoff Huston has requested that the working group adopt the draft "CA = Key Rollover in the RPKI" draft-huston-sidr-keyroll-00.txt. This draft = was announced on July 26. This wg chair apologizes to the authors for = the delay in making the requested wg call for adoption. >=20 > The draft is available at > http://www.ietf.org/id/draft-huston-sidr-keyroll-00.txt > http://tools.ietf.org/html/draft-huston-sidr-keyroll-00 >=20 > The draft was presented at the sidr meeting in IETF78 in Maastricht, = NL. The slides are available at = http://www.ietf.org/proceedings/78/slides/sidr-7.pdf. >=20 > Recall that active support for adoption is necessary for the wg chairs = to judge acceptance as a working group work item, so silence works = against adoption. The wg chairs also want to know who would be willing = to work on the draft. >=20 > Please respond to the list, giving your recommendation for or against = adoption of the draft as a wg work item as well as your intention to = work > on the draft if adopted. The call for adoption will end in two weeks = on 8 Sep 2010. >=20 > --Sandy, speaking as wg chair >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Wed Aug 25 16:01:24 2010 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 CED103A6A15 for ; Wed, 25 Aug 2010 16:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 Z5HrVEgHf16H for ; Wed, 25 Aug 2010 16:01:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 116A33A684D for ; Wed, 25 Aug 2010 16:01:24 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55446 helo=[169.223.10.196]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoOyi-000AOu-69; Wed, 25 Aug 2010 19:01:56 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 25 Aug 2010 18:26:19 -0400 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] removing TLS from the provisioning protocol 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, 25 Aug 2010 23:01:24 -0000 At 4:18 AM -0400 8/25/10, Sandra Murphy wrote: >We had a discussion in April on the list regarding removing TLS from >the provisioning protocol. Rob Austein presented his views on the >issue at the sidr meeting at the IETF78 in Maastricht. > >I am calling for wg consensus on the question. Should the authors >of draft-ietf-sidr-rescerts-provisioning-06 revise that draft to >remove TLS from the protocol? > >Please respond to the list by 8 Sept, so the authors can represent >wg consensus in the draft. > >--Sandy I am in favor of dropping the TLS requirement, and replacing it with the anti-replay mechanism (based on a time stamp?) that Rob proposed. Steve From kent@bbn.com Wed Aug 25 16:01:31 2010 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 B58203A6A7D for ; Wed, 25 Aug 2010 16:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.131, 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 5b1nNOZ9ubGh for ; Wed, 25 Aug 2010 16:01:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 40F233A694C for ; Wed, 25 Aug 2010 16:01:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55446 helo=[169.223.10.196]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoOym-000AOu-Kp; Wed, 25 Aug 2010 19:02:01 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 25 Aug 2010 18:31:01 -0400 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] WG adoption of draft-huston-sidr-keyroll-00.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: Wed, 25 Aug 2010 23:01:31 -0000 At 4:23 AM -0400 8/25/10, Sandra Murphy wrote: >Geoff Huston has requested that the working group adopt the draft >"CA Key Rollover in the RPKI" draft-huston-sidr-keyroll-00.txt. >This draft was announced on July 26. This wg chair apologizes to >the authors for the delay in making the requested wg call for >adoption. > >The draft is available at >http://www.ietf.org/id/draft-huston-sidr-keyroll-00.txt >http://tools.ietf.org/html/draft-huston-sidr-keyroll-00 > >The draft was presented at the sidr meeting in IETF78 in Maastricht, >NL. The slides are available at >http://www.ietf.org/proceedings/78/slides/sidr-7.pdf. > I am in favor of adopting this document as a starting point for standardizing this critical aspect of the RPKI. Steve , (speaking not only as the co-author :-)) From terry.manderson@icann.org Wed Aug 25 16:02:36 2010 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 DB2D03A68E0 for ; Wed, 25 Aug 2010 16:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.037 X-Spam-Level: X-Spam-Status: No, score=-106.037 tagged_above=-999 required=5 tests=[AWL=0.562, 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 SOxr47CYui9P for ; Wed, 25 Aug 2010 16:02:36 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 2DD513A68A5 for ; Wed, 25 Aug 2010 16:02:36 -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; Wed, 25 Aug 2010 16:03:09 -0700 From: Terry Manderson To: Sandra Murphy , "sidr@ietf.org" Date: Wed, 25 Aug 2010 16:03:08 -0700 Thread-Topic: [sidr] removing TLS from the provisioning protocol Thread-Index: ActELjCnOfqDiC73RISPXZBxpt6SZAAe332n 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 Subject: Re: [sidr] removing TLS from the provisioning protocol 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, 25 Aug 2010 23:02:36 -0000 I most certainly believe that the authors should remove TLS from the protocol. Cheers Terry On 25/08/10 6:18 PM, "Sandra Murphy" wrote: > We had a discussion in April on the list regarding removing TLS from the > provisioning protocol. Rob Austein presented his views on the issue at > the sidr meeting at the IETF78 in Maastricht. >=20 > I am calling for wg consensus on the question. Should the authors of > draft-ietf-sidr-rescerts-provisioning-06 revise that draft to remove TLS > from the protocol? >=20 > Please respond to the list by 8 Sept, so the authors can represent wg > consensus in the draft. From terry.manderson@icann.org Wed Aug 25 16:13:49 2010 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 A4EA13A6B46 for ; Wed, 25 Aug 2010 16:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.084 X-Spam-Level: X-Spam-Status: No, score=-106.084 tagged_above=-999 required=5 tests=[AWL=0.515, 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 HexdKlxQuITY for ; Wed, 25 Aug 2010 16:13:48 -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 669973A6B36 for ; Wed, 25 Aug 2010 16:13:48 -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; Wed, 25 Aug 2010 16:14:21 -0700 From: Terry Manderson To: Sandra Murphy , "sidr@ietf.org" Date: Wed, 25 Aug 2010 16:14:18 -0700 Thread-Topic: [sidr] WG adoption of draft-huston-sidr-keyroll-00.txt Thread-Index: ActELtR7oX2b95VWQRmzyORZKVg9zQAfGl+t 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 Subject: Re: [sidr] WG adoption of draft-huston-sidr-keyroll-00.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: Wed, 25 Aug 2010 23:13:49 -0000 I support this draft for adoption as a workgroup item, I further express my appreciation to the authors for being somewhat parsimonious in describing something that could be painfully verbose. Cheers Terry On 25/08/10 6:23 PM, "Sandra Murphy" wrote: > Geoff Huston has requested that the working group adopt the draft > "CA Key Rollover in the RPKI" draft-huston-sidr-keyroll-00.txt. This > draft was announced on July 26. This wg chair apologizes to the authors > for the delay in making the requested wg call for adoption. >=20 > The draft is available at > http://www.ietf.org/id/draft-huston-sidr-keyroll-00.txt > http://tools.ietf.org/html/draft-huston-sidr-keyroll-00 >=20 > The draft was presented at the sidr meeting in IETF78 in Maastricht, NL. > The slides are available at > http://www.ietf.org/proceedings/78/slides/sidr-7.pdf. >=20 > Recall that active support for adoption is necessary for the wg chairs to > judge acceptance as a working group work item, so silence works against > adoption. The wg chairs also want to know who would be willing to work o= n > the draft. >=20 > Please respond to the list, giving your recommendation for or against > adoption of the draft as a wg work item as well as your intention to work > on the draft if adopted. The call for adoption will end in two weeks on > 8 Sep 2010. >=20 > --Sandy, speaking as wg chair >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From gary@apnic.net Wed Aug 25 16:18:41 2010 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 83F103A6B36 for ; Wed, 25 Aug 2010 16:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0xfN51KgMmt for ; Wed, 25 Aug 2010 16:18:40 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id CBD373A6A7D for ; Wed, 25 Aug 2010 16:18:39 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:217:f2ff:fed3:df11] (unknown [IPv6:2001:dc0:a000:4:217:f2ff:fed3:df11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 5487ED589E; Thu, 26 Aug 2010 09:19:11 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Gary Kennedy In-Reply-To: Date: Thu, 26 Aug 2010 09:19:11 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: sidr@ietf.org, Sandra Murphy X-Mailer: Apple Mail (2.1081) Subject: Re: [sidr] WG adoption of draft-huston-sidr-keyroll-00.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: Wed, 25 Aug 2010 23:18:41 -0000 I support this Gary On 25/08/2010, at 6:23 PM, Sandra Murphy wrote: > Geoff Huston has requested that the working group adopt the draft "CA = Key Rollover in the RPKI" draft-huston-sidr-keyroll-00.txt. This draft = was announced on July 26. This wg chair apologizes to the authors for = the delay in making the requested wg call for adoption. >=20 > The draft is available at > http://www.ietf.org/id/draft-huston-sidr-keyroll-00.txt > http://tools.ietf.org/html/draft-huston-sidr-keyroll-00 >=20 > The draft was presented at the sidr meeting in IETF78 in Maastricht, = NL. The slides are available at = http://www.ietf.org/proceedings/78/slides/sidr-7.pdf. >=20 > Recall that active support for adoption is necessary for the wg chairs = to judge acceptance as a working group work item, so silence works = against adoption. The wg chairs also want to know who would be willing = to work on the draft. >=20 > Please respond to the list, giving your recommendation for or against = adoption of the draft as a wg work item as well as your intention to = work > on the draft if adopted. The call for adoption will end in two weeks = on 8 Sep 2010. >=20 > --Sandy, speaking as wg chair >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From tim@ripe.net Wed Aug 25 16:19:40 2010 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 5575B3A68A5 for ; Wed, 25 Aug 2010 16:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 7VMyzqMojsuH for ; Wed, 25 Aug 2010 16:19:39 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id F2C073A689B for ; Wed, 25 Aug 2010 16:19:38 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OoPGE-0007Pp-S7 for sidr@ietf.org; Thu, 26 Aug 2010 01:20:08 +0200 Received: from timbru.vpn.ripe.net ([193.0.21.62] helo=213.10.dhcp.conference.apricot.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OoPGE-0002MT-8q for sidr@ietf.org; Thu, 26 Aug 2010 01:20:02 +0200 Message-ID: <4C75A51F.9090907@ripe.net> Date: Thu, 26 Aug 2010 09:19:59 +1000 From: Tim Bruijnzeels User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071986e32a12d2b57cc252159db5e7a8daf8 X-RIPE-Spam-Level: -- X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071986e32a12d2b57cc252159db5e7a8daf8 Subject: Re: [sidr] WG adoption of draft-huston-sidr-keyroll-00.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: Wed, 25 Aug 2010 23:19:40 -0000 On 8/25/10 6:23 PM, Sandra Murphy wrote: > Geoff Huston has requested that the working group adopt the draft "CA > Key Rollover in the RPKI" draft-huston-sidr-keyroll-00.txt. This draft > was announced on July 26. This wg chair apologizes to the authors for > the delay in making the requested wg call for adoption. I support adoption. From tim@ripe.net Wed Aug 25 16:23:04 2010 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 2D8AB3A6A35 for ; Wed, 25 Aug 2010 16:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.338, 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 sYJL+Wmje762 for ; Wed, 25 Aug 2010 16:23:03 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 5129E3A689B for ; Wed, 25 Aug 2010 16:23:03 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OoPJa-0007Wd-BH for sidr@ietf.org; Thu, 26 Aug 2010 01:23:35 +0200 Received: from timbru.vpn.ripe.net ([193.0.21.62] helo=213.10.dhcp.conference.apricot.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OoPJZ-0005Zq-Qe for sidr@ietf.org; Thu, 26 Aug 2010 01:23:30 +0200 Message-ID: <4C75A5EF.9040404@ripe.net> Date: Thu, 26 Aug 2010 09:23:27 +1000 From: Tim Bruijnzeels User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719b034d14e6b87c8f6fb1265fcfc1d685e X-RIPE-Spam-Level: -- X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719b034d14e6b87c8f6fb1265fcfc1d685e Subject: Re: [sidr] removing TLS from the provisioning protocol 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, 25 Aug 2010 23:23:04 -0000 On 8/26/10 8:26 AM, Stephen Kent wrote: > At 4:18 AM -0400 8/25/10, Sandra Murphy wrote: >> We had a discussion in April on the list regarding removing TLS from >> the provisioning protocol. Rob Austein presented his views on the >> issue at the sidr meeting at the IETF78 in Maastricht. >> >> I am calling for wg consensus on the question. Should the authors of >> draft-ietf-sidr-rescerts-provisioning-06 revise that draft to remove >> TLS from the protocol? >> >> Please respond to the list by 8 Sept, so the authors can represent wg >> consensus in the draft. >> >> --Sandy > > I am in favor of dropping the TLS requirement, and replacing it with the > anti-replay mechanism (based on a time stamp?) that Rob proposed. > +1 From terry.manderson@icann.org Wed Aug 25 16:24:05 2010 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 187063A6B46 for ; Wed, 25 Aug 2010 16:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.124 X-Spam-Level: X-Spam-Status: No, score=-106.124 tagged_above=-999 required=5 tests=[AWL=0.475, 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 yw8SKnI3aSVe for ; Wed, 25 Aug 2010 16:24:04 -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 224463A6A35 for ; Wed, 25 Aug 2010 16:24:04 -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; Wed, 25 Aug 2010 16:24:37 -0700 From: Terry Manderson To: Sandra Murphy , "sidr@ietf.org" Date: Wed, 25 Aug 2010 16:24:36 -0700 Thread-Topic: [sidr] adopting alternate trust format in draft-ietf-sidr-ta-04 Thread-Index: ActELzIZtTTcGP5DRW+DeTHy95+SUgAfXw5z 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 Subject: Re: [sidr] adopting alternate trust format in draft-ietf-sidr-ta-04 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, 25 Aug 2010 23:24:05 -0000 I support the use of this alternative format. Cheers Terry On 25/08/10 6:25 PM, "Sandra Murphy" wrote: > Forgot to add the obligatory coda: >=20 > On Wed, 25 Aug 2010, Sandra Murphy wrote: >=20 >> Draft draft-weiler-sidr-trust-anchor-format-00.txt suggests an alternate >> trust anchor representation format from that proposed in >> draft-ietf-sidr-ta-04. This alternate format was discussed in the sidr >> meeting in IETF78 in Maastricht. >>=20 >> I am asking for comment on the list as to whether there is wg consensus = that >> draft-ietf-sidr-ta-04 should use the alternative format. >>=20 >> Please respond so that the authors can represent wg consensus in the dra= ft. >> The call for consensus will end Sept 8. >>=20 >> --Sandy >=20 > --Sandy, speaking as wg chair >=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From robertl@apnic.net Wed Aug 25 16:26:40 2010 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 93FFA3A6A35 for ; Wed, 25 Aug 2010 16:26:40 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMuc6gcrZ4Ye for ; Wed, 25 Aug 2010 16:26:39 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id A07AB3A689B for ; Wed, 25 Aug 2010 16:26:38 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:21f:5bff:fef1:8eb9] (unknown [IPv6:2001:dc0:a000:4:21f:5bff:fef1:8eb9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id E664DD58C0 for ; Thu, 26 Aug 2010 09:27:05 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Robert Loomans In-Reply-To: Date: Thu, 26 Aug 2010 09:27:05 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <528A2A6C-22A5-44B3-8F17-408904E22158@apnic.net> References: To: sidr@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [sidr] WG adoption of draft-huston-sidr-keyroll-00.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: Wed, 25 Aug 2010 23:26:40 -0000 I support adoption and am willing to review. Rob On 25/08/2010, at 18:23, Sandra Murphy wrote: > Geoff Huston has requested that the working group adopt the draft "CA = Key Rollover in the RPKI" draft-huston-sidr-keyroll-00.txt. This draft = was announced on July 26. This wg chair apologizes to the authors for = the delay in making the requested wg call for adoption. >=20 > The draft is available at > http://www.ietf.org/id/draft-huston-sidr-keyroll-00.txt > http://tools.ietf.org/html/draft-huston-sidr-keyroll-00 >=20 > The draft was presented at the sidr meeting in IETF78 in Maastricht, = NL. The slides are available at = http://www.ietf.org/proceedings/78/slides/sidr-7.pdf. >=20 > Recall that active support for adoption is necessary for the wg chairs = to judge acceptance as a working group work item, so silence works = against adoption. The wg chairs also want to know who would be willing = to work on the draft. >=20 > Please respond to the list, giving your recommendation for or against = adoption of the draft as a wg work item as well as your intention to = work > on the draft if adopted. The call for adoption will end in two weeks = on 8 Sep 2010. >=20 > --Sandy, speaking as wg chair >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --=20 Robert Loomans email: robertl@apnic.net Senior Software Engineer, APNIC sip: robertl@voip.apnic.net http://www.apnic.net/ phone: +61 7 3858 3100 From kent@bbn.com Wed Aug 25 16:27:42 2010 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 C0DAC3A689B for ; Wed, 25 Aug 2010 16:27:42 -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 7vTn9PFrBJbe for ; Wed, 25 Aug 2010 16:27:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id E62FB3A6B60 for ; Wed, 25 Aug 2010 16:27:41 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37987 helo=[169.223.10.196]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoPOA-000AgK-AB; Wed, 25 Aug 2010 19:28:14 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 25 Aug 2010 19:27:54 -0400 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] adopting alternate trust format in draft-ietf-sidr-ta-04 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, 25 Aug 2010 23:27:42 -0000 At 4:18 AM -0400 8/25/10, Sandra Murphy wrote: >Draft draft-weiler-sidr-trust-anchor-format-00.txt suggests an >alternate trust anchor representation format from that proposed in >draft-ietf-sidr-ta-04. This alternate format was discussed in the >sidr meeting in IETF78 in Maastricht. > >I am asking for comment on the list as to whether there is wg >consensus that draft-ietf-sidr-ta-04 should use the alternative >format. > >Please respond so that the authors can represent wg consensus in the >draft. The call for consensus will end Sept 8. > >--Sandy I am in favor of the WG switching to the simpler format, but only if the issues I raised on the list and at the meeting are addressed. Also, I would not characterize the question as you did above. Isn't the proposal for a (hopefully revised) version of Sam's draft to replace sidr-ta-04? Steve From gih@apnic.net Wed Aug 25 17:01:55 2010 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 C5E383A69D4 for ; Wed, 25 Aug 2010 17:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.253 X-Spam-Level: X-Spam-Status: No, score=-101.253 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RELAY_IS_203=0.994, 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 Ckq2UCpRKymy for ; Wed, 25 Aug 2010 17:01:55 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 331AE3A689B for ; Wed, 25 Aug 2010 17:01:54 -0700 (PDT) Received: from dhcp71.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 19F66D589E; Thu, 26 Aug 2010 10:02:18 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 26 Aug 2010 10:02:12 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <60A59971-AA89-45A5-9C81-5F3C860F264F@apnic.net> References: To: Stephen Kent , Sam Weiler X-Mailer: Apple Mail (2.1081) Cc: Sandra Murphy , sidr@ietf.org Subject: Re: [sidr] adopting alternate trust format in draft-ietf-sidr-ta-04 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, 26 Aug 2010 00:01:55 -0000 On 26/08/2010, at 9:27 AM, Stephen Kent wrote: > At 4:18 AM -0400 8/25/10, Sandra Murphy wrote: >> Draft draft-weiler-sidr-trust-anchor-format-00.txt suggests an = alternate trust anchor representation format from that proposed in = draft-ietf-sidr-ta-04. This alternate format was discussed in the sidr = meeting in IETF78 in Maastricht. >>=20 >> I am asking for comment on the list as to whether there is wg = consensus that draft-ietf-sidr-ta-04 should use the alternative format. >>=20 >> Please respond so that the authors can represent wg consensus in the = draft. The call for consensus will end Sept 8. >>=20 >> --Sandy >=20 > I am in favor of the WG switching to the simpler format, but only if = the issues I raised on the list and at the meeting are addressed. Also, = I would not characterize the question as you did above. Isn't the = proposal for a (hopefully revised) version of Sam's draft to replace = sidr-ta-04? I am happy to work with Sam to produce a single co-edited draft, if Sam = is equally willing to do so. Sam? Geoff From randy@psg.com Wed Aug 25 18:04:17 2010 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 14DFA3A6A0A for ; Wed, 25 Aug 2010 18:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 sDG4Dn1BFzW5 for ; Wed, 25 Aug 2010 18:04:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 1A2CA3A68C3 for ; Wed, 25 Aug 2010 18:04:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoQtb-000EH6-3r; Thu, 26 Aug 2010 01:04:47 +0000 Date: Thu, 26 Aug 2010 10:04:46 +0900 Message-ID: From: Randy Bush To: Stephen Kent 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] adopting alternate trust format in draft-ietf-sidr-ta-04 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, 26 Aug 2010 01:04:17 -0000 > Also, I would not characterize the question as you did above. Isn't > the proposal for a (hopefully revised) version of Sam's draft to > replace sidr-ta-04? indeed. sam's draft should replace. randy From sandy@tislabs.com Thu Aug 26 00:05:17 2010 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 1ECEA3A6407 for ; Thu, 26 Aug 2010 00:05:17 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfWI+Ficf15I for ; Thu, 26 Aug 2010 00:05:11 -0700 (PDT) Received: from nutshell.tislabs.com (ns1.tislabs.com [192.94.214.100]) by core3.amsl.com (Postfix) with ESMTP id EE53F3A6A72 for ; Thu, 26 Aug 2010 00:05:04 -0700 (PDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id o7Q73MiT025421; Thu, 26 Aug 2010 03:03:22 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAd9aGPX; Thu, 26 Aug 10 03:03:22 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 8D7123F43C; Thu, 26 Aug 2010 03:02:58 -0400 (EDT) To: kent@bbn.com, Sandra.Murphy@sparta.com In-Reply-To: Message-Id: <20100826070258.8D7123F43C@pecan.tislabs.com> Date: Thu, 26 Aug 2010 03:02:58 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) Cc: sidr@ietf.org Subject: Re: [sidr] adopting alternate trust format in draft-ietf-sidr-ta-04 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, 26 Aug 2010 07:05:17 -0000 >I am in favor of the WG switching to the simpler format, but only if >the issues I raised on the list and at the meeting are addressed. Good. >Also, I would not characterize the question as you did above. Isn't >the proposal for a (hopefully revised) version of Sam's draft to >replace sidr-ta-04? Sam's message to the list said: >I encourage the WG to adopt this format in place of the one in the current WG doc. I read that as asking for adoption of the format in the current draft, not of adoption of an alternate draft. Not that it matters, actually. The same (revised) format would result in either case. --Sandy, speaking as wg chair. From sra@hactrn.net Thu Aug 26 12:11:45 2010 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 382923A687E for ; Thu, 26 Aug 2010 12:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQJzY+z1hlL0 for ; Thu, 26 Aug 2010 12:11:43 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 68ED73A67C0 for ; Thu, 26 Aug 2010 12:11:43 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id A8F142844E for ; Thu, 26 Aug 2010 19:12:14 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5717F22829 for ; Thu, 26 Aug 2010 15:12:14 -0400 (EDT) Date: Thu, 26 Aug 2010 15:12:14 -0400 From: Rob Austein To: sidr@ietf.org 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: <20100826191214.5717F22829@thrintun.hactrn.net> Subject: Re: [sidr] removing TLS from the provisioning protocol 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, 26 Aug 2010 19:11:45 -0000 At Wed, 25 Aug 2010 04:18:43 -0400 (Eastern Daylight Time), Sandra Murphy wrote: > > We had a discussion in April on the list regarding removing TLS from the > provisioning protocol. Rob Austein presented his views on the issue at > the sidr meeting at the IETF78 in Maastricht. > > I am calling for wg consensus on the question. Should the authors of > draft-ietf-sidr-rescerts-provisioning-06 revise that draft to remove TLS > from the protocol? Yes :) From sra@hactrn.net Thu Aug 26 12:15:06 2010 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 E3CF03A67C0 for ; Thu, 26 Aug 2010 12:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9P2lGFqO-31 for ; Thu, 26 Aug 2010 12:14:57 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 3EBE83A67B5 for ; Thu, 26 Aug 2010 12:14:56 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 8E14828470 for ; Thu, 26 Aug 2010 19:15:28 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 477FD22829 for ; Thu, 26 Aug 2010 15:15:28 -0400 (EDT) Date: Thu, 26 Aug 2010 15:15:28 -0400 From: Rob Austein To: sidr@ietf.org 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: <20100826191528.477FD22829@thrintun.hactrn.net> Subject: Re: [sidr] adopting alternate trust format in draft-ietf-sidr-ta-04 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, 26 Aug 2010 19:15:06 -0000 At Wed, 25 Aug 2010 04:18:32 -0400 (Eastern Daylight Time), Sandra Murphy wrote: > > Draft draft-weiler-sidr-trust-anchor-format-00.txt suggests an alternate > trust anchor representation format from that proposed in > draft-ietf-sidr-ta-04. This alternate format was discussed in the sidr > meeting in IETF78 in Maastricht. > > I am asking for comment on the list as to whether there is wg consensus > that draft-ietf-sidr-ta-04 should use the alternative format. Yes, please. From sra@hactrn.net Thu Aug 26 12:25:17 2010 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 B61F03A68EF for ; Thu, 26 Aug 2010 12:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbsFi4k+WqUp for ; Thu, 26 Aug 2010 12:25:16 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id B90623A687E for ; Thu, 26 Aug 2010 12:25:16 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 093702844E for ; Thu, 26 Aug 2010 19:25:49 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id B5CE422829 for ; Thu, 26 Aug 2010 15:25:48 -0400 (EDT) Date: Thu, 26 Aug 2010 15:25:48 -0400 From: Rob Austein To: sidr@ietf.org 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: <20100826192548.B5CE422829@thrintun.hactrn.net> Subject: Re: [sidr] WG adoption of draft-achi-rpki-signed-object-00.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: Thu, 26 Aug 2010 19:25:17 -0000 At Mon, 23 Aug 2010 10:47:42 -0400 (Eastern Daylight Time), Sandra Murphy wrote: > > The working group chairs have received a request from the authors of > draft-achi-rpki-signed-object-00.txt that the working group adopt this > internet draft as a work item. > > This is the draft to which Matt Lepinski alluded in his message of 20 Aug > 2010. As he notes, this draft is an extract of the common language from > the ROA format and manifest documents that has to do with the CMS > encapsulation for signed objects. Support. As an implementor I really want to use a common code path to validate the common portions of all objects of this general form, and would really prefer a single specification of what that code should do. :) From tim@ripe.net Thu Aug 26 16:26:19 2010 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 68A603A6837 for ; Thu, 26 Aug 2010 16:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=-1.827, BAYES_00=-2.599, HELO_DYNAMIC_HCC=4.295] 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 jRmSYe6C9WF7 for ; Thu, 26 Aug 2010 16:26:18 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 540123A67F7 for ; Thu, 26 Aug 2010 16:26:18 -0700 (PDT) Received: from dodo.ipv6.ripe.net ([2001:610:240:23::c100:1704] helo=dodo.ripe.net) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OolqG-0002u8-SK for sidr@ietf.org; Fri, 27 Aug 2010 01:26:50 +0200 Received: from timbru.vpn.ripe.net ([193.0.21.62] helo=215.11.dhcp.conference.apricot.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OolqG-0001FI-Cb for sidr@ietf.org; Fri, 27 Aug 2010 01:26:44 +0200 Message-ID: <4C76F831.5010506@ripe.net> Date: Fri, 27 Aug 2010 09:26:41 +1000 From: Tim Bruijnzeels User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071963b637fd8f4f27fc054c4ffcc433e8ee X-RIPE-Spam-Level: -- X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071963b637fd8f4f27fc054c4ffcc433e8ee Subject: Re: [sidr] WG adoption of draft-achi-rpki-signed-object-00.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: Thu, 26 Aug 2010 23:26:19 -0000 > Please respond to the list, giving your recommendation for or against > adoption of the draft as a wg work item. Support and agree with Rob Austein's comment. In our implementation we are already using a generic CMS object for ROAs and Manifests, having a dedicated draft helps making this stuff better testable in isolation. Cheers Tim From Wesley.E.George@sprint.com Fri Aug 27 10:23:28 2010 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 131523A6896 for ; Fri, 27 Aug 2010 10:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.991 X-Spam-Level: X-Spam-Status: No, score=-2.991 tagged_above=-999 required=5 tests=[AWL=-0.392, 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 DFrJZ9kRhQkm for ; Fri, 27 Aug 2010 10:23:27 -0700 (PDT) Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by core3.amsl.com (Postfix) with ESMTP id EEEAB3A6994 for ; Fri, 27 Aug 2010 10:23:26 -0700 (PDT) Received: from mail142-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 8.1.340.0; Fri, 27 Aug 2010 17:23:59 +0000 Received: from mail142-va3 (localhost.localdomain [127.0.0.1]) by mail142-va3-R.bigfish.com (Postfix) with ESMTP id 992EBF702E0; Fri, 27 Aug 2010 17:23:58 +0000 (UTC) X-SpamScore: -34 X-BigFish: VS-34(zz542N9371Pzz1202hzz8275dh1033ILz2fh87h2a8h61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail142-va3 (localhost.localdomain [127.0.0.1]) by mail142-va3 (MessageSwitch) id 1282929837136234_11734; Fri, 27 Aug 2010 17:23:57 +0000 (UTC) Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.251]) by mail142-va3.bigfish.com (Postfix) with ESMTP id 1A3061C5804F; Fri, 27 Aug 2010 17:23:57 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server (TLS) id 14.0.482.44; Fri, 27 Aug 2010 17:23:52 +0000 Received: from plswh04a.ad.sprint.com (plswh04a.corp.sprint.com [144.226.251.24]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id o7RHNo9U006546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Aug 2010 12:23:51 -0500 Received: from PLSWM01C.ad.sprint.com ([144.226.242.77]) by plswh04a.ad.sprint.com ([2002:90e2:fb18::90e2:fb18]) with mapi; Fri, 27 Aug 2010 12:23:50 -0500 From: "George, Wes E [NTK]" To: Sandra Murphy , "sidr@ietf.org" Date: Fri, 27 Aug 2010 12:23:48 -0500 Thread-Topic: [sidr] WG adoption of draft-huston-sidr-keyroll-00.txt Thread-Index: ActELs2G3qCIh4IDQdC/Oad2LD7V9QB3b1cQ 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 X-Reverse-DNS: smtpls2.sprint.com Subject: Re: [sidr] WG adoption of draft-huston-sidr-keyroll-00.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, 27 Aug 2010 17:23:28 -0000 Support Wes George -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of San= dra Murphy Sent: Wednesday, August 25, 2010 4:23 AM To: sidr@ietf.org Subject: [sidr] WG adoption of draft-huston-sidr-keyroll-00.txt Geoff Huston has requested that the working group adopt the draft "CA Key Rollover in the RPKI" draft-huston-sidr-keyroll-00.txt. This draft was announced on July 26. This wg chair apologizes to the authors for the delay in making the requested wg call for adoption. The draft is available at http://www.ietf.org/id/draft-huston-sidr-keyroll-00.txt http://tools.ietf.org/html/draft-huston-sidr-keyroll-00 The draft was presented at the sidr meeting in IETF78 in Maastricht, NL. The slides are available at http://www.ietf.org/proceedings/78/slides/sidr-7.pdf. Recall that active support for adoption is necessary for the wg chairs to judge acceptance as a working group work item, so silence works against adoption. The wg chairs also want to know who would be willing to work on the draft. Please respond to the list, giving your recommendation for or against adoption of the draft as a wg work item as well as your intention to work on the draft if adopted. The call for adoption will end in two weeks on 8 Sep 2010. --Sandy, speaking as wg chair _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr This e-mail may contain Sprint Nextel proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If you a= re not the intended recipient, please contact the sender and delete all cop= ies of the message. From root@core3.amsl.com Sat Aug 28 23:15:08 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F332D3A67CF; Sat, 28 Aug 2010 23:15:07 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100829061507.F332D3A67CF@core3.amsl.com> Date: Sat, 28 Aug 2010 23:15:07 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-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: Sun, 29 Aug 2010 06:15:08 -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-02.txt Pages : 20 Date : 2010-08-28 In order to formally validate the origin ASes 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-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-rpki-rtr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-28231400.I-D@ietf.org> --NextPart-- From hbahadili@gmail.com Sun Aug 29 15:14:59 2010 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 A7A063A67EF for ; Sun, 29 Aug 2010 15:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRpvMRAb3aYm for ; Sun, 29 Aug 2010 15:14:54 -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 6DB273A67DA for ; Sun, 29 Aug 2010 15:14:53 -0700 (PDT) Received: by wyi11 with SMTP id 11so6441808wyi.31 for ; Sun, 29 Aug 2010 15:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=vPiwQyfx18xm2cuDoMoc36N2GIZ2vODk9QqrCSB9UAE=; b=fBBW0NHLl4+5oBCc8stKVuR/r6+qHN2MYnSd43zwFIuywbHGRuo6VyRhZ4xEp/prHE GS43oS00ez5Znc08mW14fLox9OkVN+X1bNheY0Av/Q/fxZYrFZnkHwy6AGUTTdHrf1Ru EpRNC6VQJgct+o9BLuzea+6tOSz4s6q3UQL60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LDMkYVZoSUw0lJoAwfpRUwNVXkltKYExyIecve8gm4LCHCkVpraGG72WOzwIo6Q6Es ditxd0/IGK1dZtJ73kNNq3ggSqxmt7ZHT6uae1rofPraafQryurM6OnPgWz91dW9xLEm QjhiZZ0keDvCH9tUegIUDRB8oO2ICn6CpECuo= MIME-Version: 1.0 Received: by 10.227.157.138 with SMTP id b10mr3819040wbx.13.1283120124189; Sun, 29 Aug 2010 15:15:24 -0700 (PDT) Received: by 10.216.234.146 with HTTP; Sun, 29 Aug 2010 15:15:24 -0700 (PDT) Date: Mon, 30 Aug 2010 01:15:24 +0300 Message-ID: From: Hussein Al-Bahadili To: sidr@ietf.org Content-Type: multipart/alternative; boundary=001636833e9a34fdbd048efdaf98 Subject: [sidr] CFC - Simulation in Computer Network Design and Modeling: Use and Analysis (Deadline: 31 August 2010) 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, 29 Aug 2010 22:14:59 -0000 --001636833e9a34fdbd048efdaf98 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable *Simulation in Computer Network Design and Modeling: Use and Analysis* Editor *Hussein Al-Bahadili* *The Arab Academy for Banking & Financial Sciences, Jordan, ** hbahadili@gmail.com* * * Publisher *IGI Global (formerly Idea Group Inc.), **www.igi-global.com* ** * * *Call for Chapters: * Proposals submission deadline: *June 30, 2010** **August 31, 2010 (Exteded Deadline)* Full chapters submission deadline: *October 30, 2010* *Introduction* Prospective authors are invited to submit manuscripts for possible publication in *Simulation in Computer Network Design and Modeling: Use and Analysis*. This book will publish original material concerned with all aspects of simulation on computer network design, modeling, analysis, management, security, and performance evaluation. The primary mission of th= e book is to be influential in the improvement and development of the theory and practice of computer network design and modeling, appealing to academics, researchers, and professionals. In the information technology ag= e and with tremendous advancement in computer and communication technologies, computer networks have become an integral part of many organizations. It is our further aim to provide enough examples to educate organizations on how they can benefit from simulation to design, evaluate the performance, and manage these valuable resources. Computer simulation is widely-used in investigating the performance o= f existing and proposed computer networks designs, protocols, algorithms, models, etc. The application of computer simulation can potentially improve the quality and effectiveness of the network design and modeling. It is generally unfeasible to implement a computer network design, protocol, algorithm, or model before valid tests are performed to evaluate their performance. It is clear that testing and evaluating such implementations with real hardware is quite hard, in terms of the manpower, time, and other resources. The preferred alternative is to model these algorithms in a detailed simulator and then perform various scenarios to measure their performance for various patterns of realistic computer networks environment= s (e.g., connection media, node densities, node mobility, transmission range, size of traffic, etc.). The main challenge to simulation is to model the process as close as possible to reality; otherwise it could produce entirel= y different performance characteristics from the ones discovered during actua= l use. In addition, the simulation study must be repeatable, unbiased, r ealistic, statistically sound, and cost-effective. * * *Objectives of the Book* The main objectives of this book is to: present state-of-the-art methodologies in computer networks simulation and modeling; illustrate the benefits of simulation in computer networks design, modeling, and analysis; Identify the main issues that face efficient and effective computer network simulation; demonstrate by example how the performance of computer networks can be evaluated; provide cutting edge research on the simulation and modeling of computer networks; present the trends in computer networks simulation and modeling; discuss the main features of current simulation languages; point-out the main trends in simulation languages and tools; introduce the most popular academic and professional computer networks simulators; and finally provide a complete compilation of the problems whic= h arise during the use of simulation in computer network design and modeling, and the solutions which are applied to them. *Recommended Topics* Recommended topics include, but are not limited to, the following: =B7 Simulations techniques =B7 Simulation in design and modeling of - Wireless PANs, LANs, MANs, WANs - Access point and mobile ad hoc networks - Wireless intelligent networks - Mesh networks - Wireless network algorithms and protocols - Integrated wired/wireless systems - Wireless multimedia systems - QoS provisioning in wireless and mobile networks - Security and privacy of mobile/wireless systems - Algorithms and protocols for energy-efficiency and power control - Cellular networks =B7 Computer networks simulators =B7 Formal simulation and analysis of wireless systems =B7 Simulation languages and tools for wireless systems =B7 Mobility modeling and simulation =B7 RF channel modeling, simulation, and analysis for different types= of wireless networks =B7 Models and protocols for cognitive radio networks =B7 Capacity, coverage, and connectivity modeling and analysis =B7 Model and protocols for next generation networking =B7 Performance evaluation of computer networks =B7 Performance and resource management of computer networks =B7 Performance and management of wireless multimedia systems =B7 Performance and Management of broadband wireless management =B7 Resource allocation in computer and cellular networks =B7 Traffic measurement and analysis (wireless TCP, etc.) =B7 Wireless security management =B7 Interoperability and performance of heterogeneous wireless networ= ks of different standards =B7 Correctness, survivability and reliability evaluation * * *Target Audience* The intended audience includes academics, researchers, post-graduate students, developers, professionals, network designers, network analysts, telecommunication system designers, technology specialists, practitioners, = and people who are interested in using simulation in computer network design an= d modeling. Another projected audience is the under-graduate students studyin= g at departments of computer science, computer engineering, computer networks= , computer information systems, data communication systems. The book is designed to be first choice reference at libraries at universities, academi= c institutions, research and development centers, information technology centers, and any institutions interested in using, design, modeling, and analysis of computer networks. The book is designed to be used as a textboo= k for courses teaching computer networks simulation and modeling for under/post graduate students * * *Submission Procedure* Individuals interested in submitting chapters on the above-suggested topics or other related topics should submit a 2-3 page chapter proposal clearly explaining the mission and objectives of the proposed chapter to Hussein Al-Bahadili, editor, at *hbahadili@gmail.com* = , by no later than *August 31, 2010*. We strongly encourage other topics that have not been listed in our suggested list, particularly if the topic is related to the research area in which you have expertise. Upon acceptance o= f your proposal, you will have until *October 30, 2010*, to prepare your full chapter of 8,000-10,000 words and 7-10 related terms and their appropriate definitions. Guidelines for preparing your paper and terms and definitions will be sent to you upon acceptance of your proposal. All full chapters wil= l undergo a double blind review process and chapter authors may be used as reviewers. *Publisher* This book is scheduled to be published by IGI Global (formerly Idea Group Inc.), publisher of the =93Information Science Reference=94 (formerly= Idea Group Reference), =93Medical Information Science Reference,=94 =93Business = Science Reference,=94 and =93Engineering Science Reference=94 imprints. For additio= nal information regarding the publisher, please visit www.igi-global.com. This publication is scheduled to be released in 2011. *Important Dates* =B7 Proposals submission deadline: June 30, 2010 August 31, 2010 =B7 Notification of proposals acceptance: September 15, 2010 =B7 Full chapter submission deadline: October 30, 2010 =B7 Review results to authors: January 15, 2011 =B7 Revised chapter submission deadline: February 15, 2011 =B7 Final acceptance notifications: February 28, 2011 =B7 Submission of Final Chapters deadline: March 15, 2011 *Inquiries and submissions can be forwarded electronically (Word document): * Dr. Hussein Al-Bahadili** The Arab Academy for Banking and Financial Sciences P. O. Box 13190, Amman 11942, Jordan Phone: +962 6 550 2900 (Ext. 318) Mobile: +962 796523978 Fax: +962 6 5105176 Email: hbahadili@gmail.com --001636833e9a34fdbd048efdaf98 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Simulation in Computer Network Desi= gn and Modeling: Use and Analysis

=A0

Editor

Hussein Al-Bahadili

The Arab Academy for Banking & = Financial Sciences, Jordan, hbahadili@gmail.com =A0=

=A0

Publisher

IGI Globa= l (formerly Idea Group Inc.), = www.igi-global.com

=A0

Call for Chapters: =

Proposals submission deadline: June= 30, 2010 August 31, 2010 (Exteded Deadline)

Full chapters submission deadline: October 30, 2010

Introduction

=A0= =A0=A0=A0=A0 Prospective auth= ors are invited to submit manuscripts for possible publication in Sim= ulation in Computer Network Design and Modeling: Use and Analysis. = This book will publish original material concerned with all aspects of simu= lation on computer network design, modeling, analysis, management, security= , and performance evaluation. The primary mission of the book is to be infl= uential in the improvement and development of the theory and practice of co= mputer network design and modeling, appealing to academics, researchers, an= d professionals. In the information technology age and with tremendous adva= ncement in computer and communication technologies, computer networks have = become an integral part of many organizations.=A0It is our further aim to p= rovide enough examples to educate organizations on how they can benefit fro= m simulation to design, evaluate the performance, and manage these valuable= resources.

= =A0=A0=A0=A0=A0 Computer s= imulation is widely-used in investigating the performance of existing and p= roposed computer networks designs, protocols, algorithms, models, etc. The = application of computer simulation can potentially improve the quality and = effectiveness of the network design = and modeling. It is generally unfeasible to implement a computer network design= , protocol, algorithm, or model before valid tests are performed to evaluat= e their performance. It is clear that testing and evaluating such implement= ations with real hardware is quite hard, in terms of the manpower, time, an= d other resources. The preferred alternative is to model these algorithms i= n a detailed simulator and then perform various scenarios to measure their = performance for various patterns of realistic computer networks environment= s (e.g., connection media, node densities, node mobility, transmission rang= e, size of traffic, etc.). The main challenge to simulation is to model the= process as close as possible to reality; otherwise it could produce entire= ly different performance characteristics from the ones discovered during ac= tual use. In addition, the simulation study must be repeatable, unbiased, r<= /span>ealistic, statistically sound, and cost-effective.

= =A0

Objectives of the Book=

=A0=A0=A0=A0=A0 The main objectives of this book is to: present state= -of-the-art methodologies in computer networks simulation and modeling; ill= ustrate the benefits of simulation in computer networks design, modeling, a= nd analysis; Identify the main issues that face efficient and effective com= puter network simulation; demonstrate by example how the performance of com= puter networks can be evaluated; provide cutting edge research on the simul= ation and modeling of computer networks; present the trends in computer net= works simulation and modeling; discuss the main features of current simulat= ion languages; point-out the main trends in simulation languages and tools;= introduce the most popular academic and professional computer networks sim= ulators; and finally provide a complete compilation = of the problems which arise during the use of simulation in computer networ= k design and modeling, and the solutions which are applied to them.<= span style=3D"FONT-SIZE: 10pt">

=A0=

Recommended T= opics

=A0=A0=A0=A0=A0 Recommended topics include, but are not limited to, the following:<= /font>

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Simulations techniques

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Simulation in design and modeling of =A0

-= =A0=A0=A0=A0=A0 = Wireless PANs, LANs, MANs, WANs

-= =A0=A0=A0=A0=A0 = Access point and mobile ad hoc networks

-= =A0=A0=A0=A0=A0 = Wireless intelligent networks

-= =A0=A0=A0=A0=A0 = Mesh networks

-= =A0=A0=A0=A0=A0 = Wireless network algorithms and protocols<= /p>

-= =A0=A0=A0=A0=A0 = Integrated wired/wireless systems

-= =A0=A0=A0=A0=A0 = Wireless multimedia systems

-= =A0=A0=A0=A0=A0 = QoS provisioning in wireless and mobile networks<= /span>

-= =A0=A0=A0=A0=A0 = Security and privacy of mobile/wireless systems

-= =A0=A0=A0=A0=A0 = Algorithms and protocols for energy-efficiency and power= control

-= =A0=A0=A0=A0=A0 = Cellular networks

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Computer networks simulators

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Formal simulation and analysis of wireless systems<= /font>

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Simulation languages and tools for wireless systems=

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Mobility modeling and simulation

= =B7=A0=A0=A0=A0=A0=A0 <= /span>RF channel modeling, simulation, and analysis for d= ifferent types of wireless networks

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Models and protocols for cognitive radio networks

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Capacity, coverage, and connectivity modeling and a= nalysis

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Model and protocols for next generation networking<= /font>

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Performance evaluation of computer networks<= /span>

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Performance and resource management of computer net= works

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Performance and management of wireless multimedia s= ystems

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Performance and Management of broadband wireless ma= nagement

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Resource allocation in computer and cellular networ= ks

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Traffic measurement and analysis (wireless TCP, etc= .)

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Wireless security management

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Interoperability and performance of heterogeneous w= ireless networks of different standards

= =B7=A0=A0=A0=A0=A0=A0 <= /span>Correctness, survivability and reliability evaluati= on

=A0

Target Audien= ce

=A0=A0=A0=A0=A0 The intended audi= ence includes academics, researchers, post-graduate students, developers, p= rofessionals, network designers, network analysts, telecommunication system= designers, technology specialists, practitioners, an= d people who are interested in using simulation in computer network design = and modeling. Another projected audience is the under-graduate students studying at departments of computer scie= nce, computer engineering, computer networks, computer information systems,= data communication systems. The book is designed to be first choice refere= nce at libraries at universities, academic institutions, research and devel= opment centers, information technology centers, and any institutions intere= sted in using, design, modeling, and analysis of computer networks. The boo= k is designed to be used as a textbook for courses teaching computer networ= ks simulation and modeling for under/post graduate students

=A0

Submission Proc= edure

= =A0=A0=A0=A0=A0 Individuals interes= ted in submitting chapters on the above-suggested topics or other related t= opics should submit a 2-3 page chapter proposal clearly explaining the miss= ion and objectives of the proposed chapter to Hussein Al-Bahadili, editor, = at hbahadili@gmail.com, by no later than = August 31, 2010. We strongly encourage other topics that have no= t been listed in our suggested list, particularly if the topic is related t= o the research area in which you have expertise. Upon acceptance of your pr= oposal, you will have until October 30, 2010, to prepare your= full chapter of 8,000-10,000 words and 7-10 related terms and their approp= riate definitions. Guidelines for preparing your paper and terms and defini= tions will be sent to you upon acceptance of your proposal. All full chapte= rs will undergo a double blind review process and chapter authors may be us= ed as reviewers.

=A0

Publisher

<= font face=3D"Calibri">=A0=A0=A0=A0=A0 This book is scheduled to be published by IGI Global (formerly Idea Grou= p Inc.), publisher of the =93Information Science Reference=94 (formerly Ide= a Group Reference), =93Medical Information Science Reference,=94 =93Busines= s Science Reference,=94 and =93Engineering Science Reference=94 imprints. F= or additional information regarding the publisher, please visit www.igi-global.com= . This publication is scheduled to be released in 2011.

=A0

= Important Dates

=B7=A0=A0=A0=A0=A0=A0 Proposals submission deadline: June 30,= 2010 = August 31, 2010

=B7=A0=A0=A0=A0=A0=A0 Notification of proposals acceptance: September 15, 2010

=B7=A0=A0=A0=A0=A0=A0 Full chapter submission deadline: October 30, 2010<= /span>

=B7=A0=A0=A0=A0=A0=A0 Review results to authors: January 15, 2011<= /p>

=B7=A0=A0=A0=A0=A0=A0 Revised chapter submission deadline: February 15, 2011

=B7=A0=A0=A0=A0=A0=A0 Final acceptance notifications: February 28, 2011

=B7=A0=A0=A0=A0=A0=A0 Submission of Final Chapters deadline: March 15, 2011=

=A0

Inquiries and submis= sions can be forwarded electronically (Word document):

Dr. Hussein Al-Ba= hadili

The Arab Academy for Banking and Financial Sciences<= /span>

P. O. Box 13190, Amman 1= 1942, Jorda= n

Phone: +962 6 550 2900 (Ext. 318)

Mobile: +962 796523978

Fax: +962 6 5105176

Email: hbahadili@gmail.com



--001636833e9a34fdbd048efdaf98-- From warren@kumari.net Mon Aug 30 08:25:07 2010 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 D8C5E3A6827 for ; Mon, 30 Aug 2010 08:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 vch45VzNIIWj for ; Mon, 30 Aug 2010 08:25:07 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 0ED603A68A7 for ; Mon, 30 Aug 2010 08:25:07 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id 72AE9DEE002; Mon, 30 Aug 2010 11:23:51 -0400 (EDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id A0811DEE001; Mon, 30 Aug 2010 11:23:50 -0400 (EDT) Message-Id: <5464D945-5FBB-4BDF-BE8C-53272D6CD228@kumari.net> From: Warren Kumari To: Sandra Murphy In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 30 Aug 2010 11:25:36 -0400 References: X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: Re: [sidr] removing TLS from the provisioning protocol 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, 30 Aug 2010 15:25:07 -0000 On Aug 25, 2010, at 4:18 AM, Sandra Murphy wrote: > We had a discussion in April on the list regarding removing TLS from > the provisioning protocol. Rob Austein presented his views on the > issue at the sidr meeting at the IETF78 in Maastricht. > > I am calling for wg consensus on the question. Should the authors > of draft-ietf-sidr-rescerts-provisioning-06 revise that draft to > remove TLS from the protocol? Yes, yes they should... W > > Please respond to the list by 8 Sept, so the authors can represent > wg consensus in the draft. > > --Sandy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft. --Anon. From warren@kumari.net Mon Aug 30 08:26:12 2010 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 BE0733A69D3 for ; Mon, 30 Aug 2010 08:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 kf-mKYPXas-p for ; Mon, 30 Aug 2010 08:26:12 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 87D5F3A69C0 for ; Mon, 30 Aug 2010 08:26:11 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id 2E4D9DEE002; Mon, 30 Aug 2010 11:24:56 -0400 (EDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 84A43DEE001; Mon, 30 Aug 2010 11:24:55 -0400 (EDT) Message-Id: <8595AFE1-F7FC-4F1D-8BEF-142123084E06@kumari.net> From: Warren Kumari To: Sandra Murphy In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 30 Aug 2010 11:26:41 -0400 References: X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: Re: [sidr] adopting alternate trust format in draft-ietf-sidr-ta-04 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, 30 Aug 2010 15:26:12 -0000 On Aug 25, 2010, at 4:18 AM, Sandra Murphy wrote: > Draft draft-weiler-sidr-trust-anchor-format-00.txt suggests an > alternate trust anchor representation format from that proposed in > draft-ietf-sidr-ta-04. This alternate format was discussed in the > sidr meeting in IETF78 in Maastricht. > > I am asking for comment on the list as to whether there is wg > consensus that draft-ietf-sidr-ta-04 should use the alternative > format. Yup. > > Please respond so that the authors can represent wg consensus in the > draft. The call for consensus will end Sept 8. > > --Sandy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- Never criticize a man till you've walked a mile in his shoes. Then if he didn't like what you've said, he's a mile away and barefoot.