From david@mandelberg.org Tue Dec 3 11:52:51 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D301AC3DA for ; Tue, 3 Dec 2013 11:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHL2CF01UO_h for ; Tue, 3 Dec 2013 11:52:50 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5831A1F79 for ; Tue, 3 Dec 2013 11:52:50 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta05.westchester.pa.mail.comcast.net with comcast id x16Z1m0081ZXKqc557snos; Tue, 03 Dec 2013 19:52:47 +0000 Received: from uriel.mandelberg.org ([IPv6:2001:4830:11a7:2:216:3eff:fe0e:b38c]) by omta21.westchester.pa.mail.comcast.net with comcast id x7sk1m00Z1djk4J3h7snkv; Tue, 03 Dec 2013 19:52:47 +0000 Received: from secure.mandelberg.org (unknown [10.1.2.3]) by uriel.mandelberg.org (Postfix) with ESMTP id B12361C6092 for ; Tue, 3 Dec 2013 14:58:15 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 03 Dec 2013 14:58:15 -0500 From: David Mandelberg To: In-Reply-To: <52954D51.5020808@ops-netman.net> References: <52954D51.5020808@ops-netman.net> Message-ID: <445d2b5c04705b98e6d6b826783d39cc@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386100367; bh=+9qrDgvz8hM6mhwu7IqljeKe+0GQbCHxN9abLHML208=; h=Received:Received:Received:MIME-Version:Content-Type:Date:From:To: Subject:Message-ID; b=hbPAQcBcwSA01h2y6QbVV3oIht8PkjfQTCuIWD2Url7l4/rbm4Uu3e4wkJvZieYla Bs14hbTvRcXc/k5YKcNM9x615SoP1dQYU9YvrA6D/L3eHS/NcUgN0kuUG0R+w9t6yM Fb4BHDzMqvRTMQUgfrMlHJJC0YgVm/dEStMGGiNJWtiHJrSeMSL5lyEk5r9jdBsDsz xlWLA1X3/SKWwmuK2uBJc9ZY/Y6O6BIVP+lKr6larbjG7H63iBFf45XVLn/eNABM9r JKixq27LMzDE9wcP3sfdcAs9OaFKAdjV4jyy1SDzxoT7LWwc/m0EUQlB7q8lT4QrJd 7ZOcZ8z3bsxRg== Subject: Re: [sidr] WG Adoption: draft-ymbk-lta-use-cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 19:52:52 -0000 I support adoption. I think there are some parts of this doc that could use more work (and I'm happy to review). I also think that a use cases document would be helpful and this is a good starting point. On 2013-11-26 20:39, Chris Morrow wrote: > Howdy gentle WG folks, > The authors of: > > > are interested in starting a WG Adoption call for this piece of > scribed > text. It would be good if other folk also agreed about the adoption. > > The abstract says: > "There are a number of critical circumstances where a localized > routing domain needs to augment or modify the Global RPKI. This > document attempts to outline a few of them." > > Please consider this a 'WG Adoption' call, and let's attempt to close > this out by: > 12/9/2013 or 9/12/2013 or Ninth December Twenty-Thirteen or ... you > get the point, see you in 2 weeks with (hopefully) clear direction > from > the folks behind the emailz. > > -chris > co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From carlosm3011@gmail.com Wed Dec 4 16:25:35 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212831AE1B5 for ; Wed, 4 Dec 2013 16:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML311ZywqA9t for ; Wed, 4 Dec 2013 16:25:33 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id AD8E01AE195 for ; Wed, 4 Dec 2013 16:25:33 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id wp4so17191898obc.27 for ; Wed, 04 Dec 2013 16:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0jQx4eifcPMcIZgO/buJLwaHVO/IGwopvFhI6tdzEwQ=; b=qi1tEhuO74B+M6iET0xguCTh22mPVwKRN1UsLYbyAF49Oq5UXJbJHv2YmJ1uJ/1+82 sUlTKe2X/S1bKtg78OUe3uuYAtCKziA9vZUjyZw1YRzMxQ9WJ/QrMdvL11CL3nOWmITk YnB0pYTynEfq9r05x+6QdeRYbw7Tm66FOvbzTxMBnjzefE/IwPZ5UGfFihMGkMyzUt5K pHeJDZU6pGz4TUGc8UyrnQ9h7EDkm9enI6t893jzUIlHpRvtLwaOrgwjAfYD6ND6TvYS HPKvBwsAfa+J58ToRfyp0mwYh/tB52/l7VplLZ/e+IslI3ZR4CDxJPORL7Q4jxpZIT18 1PDQ== X-Received: by 10.60.98.69 with SMTP id eg5mr16484365oeb.42.1386203130397; Wed, 04 Dec 2013 16:25:30 -0800 (PST) Received: from erebus.local ([108.60.131.13]) by mx.google.com with ESMTPSA id z5sm124750336obg.13.2013.12.04.16.25.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 16:25:29 -0800 (PST) Message-ID: <529FC7F9.7020306@gmail.com> Date: Wed, 04 Dec 2013 18:25:29 -0600 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Chris Morrow , "sidr-chairs@tools.ietf.org" , sidr wg list References: <52954D51.5020808@ops-netman.net> In-Reply-To: <52954D51.5020808@ops-netman.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] WG Adoption: draft-ymbk-lta-use-cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:25:35 -0000 +1, support adoption of the requirements document On 11/26/13, 7:39 PM, Chris Morrow wrote: > Howdy gentle WG folks, > The authors of: > > > are interested in starting a WG Adoption call for this piece of scribed > text. It would be good if other folk also agreed about the adoption. > > The abstract says: > "There are a number of critical circumstances where a localized > routing domain needs to augment or modify the Global RPKI. This > document attempts to outline a few of them." > > Please consider this a 'WG Adoption' call, and let's attempt to close > this out by: > 12/9/2013 or 9/12/2013 or Ninth December Twenty-Thirteen or ... you > get the point, see you in 2 weeks with (hopefully) clear direction from > the folks behind the emailz. > > -chris > co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From carlosm3011@gmail.com Wed Dec 4 16:32:45 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C3D1AE1D7 for ; Wed, 4 Dec 2013 16:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xXMZA0UWQ43 for ; Wed, 4 Dec 2013 16:32:44 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E36DF1AE1D4 for ; Wed, 4 Dec 2013 16:32:43 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id uz6so16816549obc.6 for ; Wed, 04 Dec 2013 16:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lIt7Y4mOJ/FjqUKN3PeLps/3/kHSPvHzx/9hhXYYfFg=; b=l4stwHdX2FWUfA1mzjBcHivWm0PIZFnzJ4FYD758hZEX5UhCk9hjmPPR5Q6zYkCvMQ gmfARUFHUcUv24wdfiCdhoSlVhpHNe4TwV6r09DE9rfuorBIptttnda22Y9JvNRWUVpz 82OtpUkNLXd+haulZND6ZSDm/4AzO/nnPLXo0HGp0bft8yPgXGigkqroTzu4tAuMvcv/ FMmLXy4EKCSF4uFSGG8LjhegdOQpPlAm4ZSw9qecoUVbwOOo3/Fd7Lz4x7ZgAzXxIFJS g9dPopBK88ZPZRy8mMrRpyXJdBtzMsyRKKMyOaxzwDOOK3i2xQnRbwZxiOrjtnpkmYC2 QunA== X-Received: by 10.60.134.14 with SMTP id pg14mr3241103oeb.66.1386203560676; Wed, 04 Dec 2013 16:32:40 -0800 (PST) Received: from erebus.local ([108.60.131.13]) by mx.google.com with ESMTPSA id jz7sm112091167oeb.4.2013.12.04.16.32.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 16:32:40 -0800 (PST) Message-ID: <529FC9A8.8060106@gmail.com> Date: Wed, 04 Dec 2013 18:32:40 -0600 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Murphy, Sandra" , "sidr@ietf.org" References: <24B20D14B2CD29478C8D5D6E9CBB29F67875D4EF@HSV-MB002.huntsville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F67875D4EF@HSV-MB002.huntsville.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] wg adoption call for draft-austein-sidr-rpki-oob-setup-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:32:45 -0000 +1 for adoption cheers! ~Carlos On 11/15/13, 11:12 AM, Murphy, Sandra wrote: > The authors of draft-austein-sidr-rpki-oob-setup-00 have requested wg adoption. > > See http://tools.ietf.org/html/draft-austein-sidr-rpki-oob-setup-00 . > > Please do respond to the list as to whether you support the wg adopting this as a work item. You do not need to comment on the content of this draft at this time. You are asked to indicate if you think that this is work that the wg should be doing and whether this draft is an acceptable starting point. Adding whether you can/will review or not is useful. > > Note that active support is required for adoption. Silence is a vote against adoption. > > This adoption call will end on Monday, Dec 2. 2013, (a bit more than the usual two weeks, since both chairs will likely be out of touch on Friday, Nov 29). > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From prvs=50522304a9=sandra.murphy@parsons.com Thu Dec 5 16:47:04 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88401AE236 for ; Thu, 5 Dec 2013 16:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMWM-lujUkT1 for ; Thu, 5 Dec 2013 16:47:03 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 300661AE239 for ; Thu, 5 Dec 2013 16:47:03 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id rB60jc2f023724 for ; Thu, 5 Dec 2013 18:46:59 -0600 Received: from uther.sparta.com (uther.sparta.com [157.185.0.2]) by txdal11mx03.parsons.com with ESMTP id 1gk20mgha2-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 05 Dec 2013 18:46:59 -0600 Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id rB60kkkw016020 for ; Thu, 5 Dec 2013 16:46:46 -0800 Received: from kraven.huntsville.ads.sparta.com ([10.62.8.137]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id rB60kkLQ003187 for ; Thu, 5 Dec 2013 16:46:46 -0800 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by kraven.huntsville.ads.sparta.com ([::1]) with mapi id 14.02.0342.003; Thu, 5 Dec 2013 18:46:40 -0600 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: wg adoption call for draft-austein-sidr-rpki-oob-setup-00 Thread-Index: Ac7alCgjg0CURsWvTfKZcY9Lng/4XgXiCfmD Date: Fri, 6 Dec 2013 00:46:40 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F67876D908@HSV-MB001.huntsville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F67875D4EF@HSV-MB002.huntsville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F67875D4EF@HSV-MB002.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.72, 1.0.14, 0.0.0000 definitions=2013-12-05_07:2013-12-05,2013-12-05,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=110.568 compositescore=0.0600554693842911 urlsuspect_oldscore=0.600554693842911 suspectscore=0 recipient_domain_to_sender_totalscore=1469 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=7945 rbsscore=0.0600554693842911 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312050171 Subject: Re: [sidr] wg adoption call for draft-austein-sidr-rpki-oob-setup-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 00:47:05 -0000 The wg call for adoption has ended. The response from the wg indicates con= sensus for adoption of this as a working group work item.=0A= =0A= The authors should submit the draft with a wg formatted name (draft-ietf-si= dr-yada-yada).=0A= =0A= --Sandy, speaking as a wg co-chair=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@parsons.com]=0A= Sent: Friday, November 15, 2013 12:12 PM=0A= To: sidr@ietf.org=0A= Subject: [sidr] wg adoption call for draft-austein-sidr-rpki-oob-setup-00= =0A= =0A= The authors of draft-austein-sidr-rpki-oob-setup-00 have requested wg adopt= ion.=0A= =0A= See http://tools.ietf.org/html/draft-austein-sidr-rpki-oob-setup-00 .=0A= =0A= Please do respond to the list as to whether you support the wg adopting thi= s as a work item. You do not need to comment on the content of this draft = at this time. You are asked to indicate if you think that this is work tha= t the wg should be doing and whether this draft is an acceptable starting p= oint. Adding whether you can/will review or not is useful.=0A= =0A= Note that active support is required for adoption. Silence is a vote again= st adoption.=0A= =0A= This adoption call will end on Monday, Dec 2. 2013, (a bit more than the us= ual two weeks, since both chairs will likely be out of touch on Friday, Nov= 29).=0A= =0A= --Sandy, speaking as wg co-chair=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From prvs=50522304a9=sandra.murphy@parsons.com Thu Dec 5 16:53:00 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FDB1AE230 for ; Thu, 5 Dec 2013 16:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-2YX5glZqs6 for ; Thu, 5 Dec 2013 16:52:59 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 12CCB1AE226 for ; Thu, 5 Dec 2013 16:52:59 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id rB60npCC026849 for ; Thu, 5 Dec 2013 18:52:55 -0600 Received: from uther.sparta.com (uther.sparta.com [157.185.0.2]) by txdal11mx03.parsons.com with ESMTP id 1gk20mghsx-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 05 Dec 2013 18:52:55 -0600 Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id rB60qgxG016068 for ; Thu, 5 Dec 2013 16:52:42 -0800 Received: from kraven.huntsville.ads.sparta.com ([10.62.8.137]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id rB60qgVD003376 for ; Thu, 5 Dec 2013 16:52:42 -0800 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by kraven.huntsville.ads.sparta.com ([::1]) with mapi id 14.02.0342.003; Thu, 5 Dec 2013 18:52:36 -0600 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: a query to the wg regarding publication draft Thread-Index: AQHO3IXON5REMGrzckWEdHA42xLww5pGgOZH Date: Fri, 6 Dec 2013 00:52:36 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F67876D91D@HSV-MB001.huntsville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F678760F25@HSV-MB002.huntsville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F678760F25@HSV-MB002.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.72, 1.0.14, 0.0.0000 definitions=2013-12-05_07:2013-12-05,2013-12-05,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=230.336 compositescore=0.0549338109471868 urlsuspect_oldscore=0.549338109471868 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=12528 rbsscore=0.0549338109471868 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312050173 Subject: Re: [sidr] a query to the wg regarding publication draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 00:53:00 -0000 There have been few replies to this message (thanks to Steve and Tim for th= eir replies), perhaps because there's no deadline set to urge action.=0A= =0A= Please do respond to the list by 13 Dec with your thoughts on Rob's questio= n.=0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@parsons.com]=0A= Sent: Friday, November 08, 2013 8:25 AM=0A= To: sidr@ietf.org=0A= Subject: [sidr] a query to the wg regarding publication draft=0A= =0A= Rob posed a question to the room during the meeting on Tue (Nov 5) about th= e publication draft. See slides at http://www.ietf.org/proceedings/88/slid= es/slides-88-sidr-1.pdf.=0A= =0A= The question to the list is:=0A= =0A= Should the protocol be trimmed -- take out all of the =93control=94 operati= ons, leaving just the and operations -- or should th= e "control" operations be an optional sub-protocol?=0A= =0A= What say ye?=0A= =0A= --Sandy=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From kotikalapudi.sriram@nist.gov Thu Dec 5 17:04:41 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2111AE23D for ; Thu, 5 Dec 2013 17:04:41 -0800 (PST) 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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM4lHQQQsrfZ for ; Thu, 5 Dec 2013 17:04:39 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id A0CBC1AE237 for ; Thu, 5 Dec 2013 17:04:39 -0800 (PST) Received: from BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) by BLUPR09MB055.namprd09.prod.outlook.com (10.255.211.152) with Microsoft SMTP Server (TLS) id 15.0.825.14; Fri, 6 Dec 2013 01:04:35 +0000 Received: from BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.105]) by BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.105]) with mapi id 15.00.0825.006; Fri, 6 Dec 2013 01:04:34 +0000 From: "Sriram, Kotikalapudi" To: Chris Morrow , "sidr-chairs@tools.ietf.org" , sidr wg list Thread-Topic: [sidr] WG Adoption: draft-ymbk-lta-use-cases Thread-Index: AQHO6xGbitHKJPPrtkOREH1cn0INo5pGZv6w Date: Fri, 6 Dec 2013 01:04:34 +0000 Message-ID: <0308105c92c44b1fae220e83e39e360b@BLUPR09MB053.namprd09.prod.outlook.com> References: <52954D51.5020808@ops-netman.net> In-Reply-To: <52954D51.5020808@ops-netman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-forefront-prvs: 0052308DC6 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(51704005)(85306002)(81342001)(74366001)(87266001)(4396001)(47976001)(81542001)(80022001)(76786001)(50986001)(74706001)(49866001)(54356001)(74876001)(47736001)(74502001)(76796001)(46102001)(74316001)(69226001)(31966008)(83072001)(59766001)(53806001)(79102001)(77982001)(80976001)(63696002)(74662001)(81686001)(76482001)(87936001)(19580395003)(51856001)(2656002)(77096001)(558084003)(66066001)(33646001)(56776001)(81816001)(56816005)(65816001)(47446002)(83322001)(54316002)(76576001)(85852002)(90146001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB055; H:BLUPR09MB053.namprd09.prod.outlook.com; CLIP:129.6.140.100; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Subject: Re: [sidr] WG Adoption: draft-ymbk-lta-use-cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 01:04:41 -0000 Yes, support adoption. I'm willing to review and provide feedback. Sriram > >Howdy gentle WG folks, >The authors of: > > >are interested in starting a WG Adoption call for this piece of scribed te= xt. It >would be good if other folk also agreed about the adoption. > From prvs=50522304a9=sandra.murphy@parsons.com Thu Dec 5 17:05:28 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0381E1AE245 for ; Thu, 5 Dec 2013 17:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Km7aN5w7U4rc for ; Thu, 5 Dec 2013 17:05:24 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1B28E1AE244 for ; Thu, 5 Dec 2013 17:05:24 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id rB614sTj006685; Thu, 5 Dec 2013 19:05:20 -0600 Received: from uther.sparta.com (uther.sparta.com [157.185.0.2]) by txdal11mx03.parsons.com with ESMTP id 1gk20mgjyb-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 05 Dec 2013 19:05:19 -0600 Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id rB615IPS016126; Thu, 5 Dec 2013 17:05:18 -0800 Received: from HSV-CAS003.huntsville.ads.sparta.com ([10.62.8.138]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id rB615Idg003792; Thu, 5 Dec 2013 17:05:18 -0800 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by HSV-CAS003.huntsville.ads.sparta.com ([fe80::a415:ede2:34ef:d13f%11]) with mapi id 14.02.0342.003; Thu, 5 Dec 2013 19:05:16 -0600 From: "Murphy, Sandra" To: "Roque Gagliano (rogaglia)" , sidr wg list Thread-Topic: a new direction for draft-ietf-sidr-multiple-publication-points Thread-Index: AQHO8h8xkWqxlIUeVEKSk3p4x8e5kg== Date: Fri, 6 Dec 2013 01:05:17 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F67876D946@HSV-MB001.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F67876D946HSVMB001huntsvi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.72, 1.0.14, 0.0.0000 definitions=2013-12-05_07:2013-12-05,2013-12-05,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=85.0413531406927 compositescore=0.0161629899874375 urlsuspect_oldscore=0.600554693842911 suspectscore=0 recipient_domain_to_sender_totalscore=1469 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=2 recipient_domain_to_sender_domain_totalscore=7945 rbsscore=0.0161629899874375 spamscore=0 recipient_to_sender_domain_totalscore=2 urlsuspectscore=0.1 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312050176 Subject: [sidr] a new direction for draft-ietf-sidr-multiple-publication-points X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 01:05:28 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F67876D946HSVMB001huntsvi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The authors made a suggestion (see below) for a new course of action for th= e draft draft-ietf-sidr-multiple-publication-points, splitting the draft in= to two work items. And there have been nearly two months of mostly silence on the point. (Tha= nks to Steve and Arturo for their replies.). If the working group does not reject the approach the authors suggest by 13= Dec 2013, the authors should proceed with submission of a new version of d= raft-ietf-sidr-multiple-publication-points that meets the first proposal: - A "6490-bis" document that obsoletes RFC 6490 with the addition of multip= le operators in section 3 of the current document. and submission of an individual draft for consideration of the working grou= p that meets the second proposal: - A new BCP/Informational document on best practices when RPKI certificates= include multiple repository operators for the same materials. --Sandy, speaking as wg co-chair ________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Roque Gagl= iano (rogaglia) [rogaglia@cisco.com] Sent: Monday, October 14, 2013 3:41 PM To: sidr wg list Subject: Re: [sidr] possible interim meeting for draft-ietf-sidr-multiple-p= ublication-points Dear Working Group: The co-authors of the multi-publication points document would like to propo= se a new course of action to the WG referring to this document. Since its initial submission, the document addresses two problems related t= o the support of multiple operators in RPKI: i)- Multiple Operators support in TAL files (Section 3 of current document= ) ii)- Multiple Operators support in Certificates (Section 4 of current docum= ent) Today, we believe that the two problems are very different. On one side po= int i) could be quickly solved by the WG by updating or obsoleting RFC 6490= with the changes proposed in Section 3 of the document. We have shown in B= erlin that changes to RPs should be very small and that "some" (and I say s= o because in some cases it was accidental) backward compatibility exists wi= th most popular RPs. However the second point ii) while it does not require changes to existing = standard document but rather a "BCP" document, it does require much more re= search. While we go down to the RPKI hierarchy, we need to understand how m= ultiple operators may create transient states and how RPs will typically re= act to these. Some of the questions to answer were raised at the meeting an= d recently in the WG mailing list. Our proposal to the group is to split the current content in the document i= n two documents: - A "6490-bis" document that obsoletes RFC 6490 with the addition of multip= le operators in section 3 of the current document. - A new BCP/Informational document on best practices when RPKI certificates= include multiple repository operators for the same materials. We look forward to hearing from you, Regards, Roque + Carlos + Terry On Oct 2, 2013, at 9:58 AM, Roque Gagliano (rogaglia) > wrote: Thanks Sharon for your email and analysis. These points are some of the poi= nts raised during our last meeting. I personally believe that the non-TAL work requires more research activity = and I guess from your email that you have an interest in this area :-). Regards, Roque Hi Roque, As you work on this, I wanted share some observations made by my colleague = here at BU, Ethan Heilman. He read the draft in detail and had a two sugges= tions and one question, see below. Sharon Suggestion 1: Section 4.1 of the draft says: =93If the connection to the preferred URI fa= ils, the RP SHOULD fetch the repository objects from the next URI of prefer= ence." We suggest that the failover logic be extended to include validation failur= es as well as connection failures (similar to the logic for TALs). That is,= when RPKI-validation generates a warning, an RP should fail over to anothe= r publication point. These warnings could be generated by stale manifests, = manifest errors (http://tools.ietf.org/html/rfc6486), expired certs, miss= ing ROAs, and other validation failures. We call this failover mode FO-Corr= upt (Failover On Corruption) as opposed to the current failover mode FO-Con= nect (Failover On Connection failure) in the draft. Here=92s why we sugges= t FO-Corrupt: 1) Multiple publication points using the FO-Connect policy increase th= e attack surface, while multiple publication points using the FO-Corrupt po= licy decrease the attack surface. With FO-Connect, corruption failures in = a given publication point will directly affect RPs that select that publica= tion point. Meanwhile, under FO-Corrupt, a corruption failure must occur o= n all publication points before it affects RPs; each additional publication= point adds an additional barrier to an attacker that seeks to corrupt obje= cts. This also allows operators to raise the cost of an attack by adding pu= blication points using diverse software and operating systems. Importantly= , missing or corrupted RPKI objects can cause routes to become classified a= s invalid, and therefore be less preferred -- I provide examples of this ha= ppening in the attached PDF =96 so if some of the publication points contai= n uncorrupted objects, it=92s important to ensure that RP=92s fetch them. 2) The differences in behavior between TAL failover and RPKI object fa= ilover could cause confusion. FO-Corrupt would provide a more consistent= policy. Compare the quote from Section 4.1 above with the following from= Section 3.2: =93If the connection to the preferred URI fails or t= he fetched certificate public key does not match the TAL public key, the RP= SHOULD fetch the TA certificate from the next URI of preference.=94 Suggestion 2: Section 3.2 and 4.1 of the draft suggest three rules to select the URI of t= he publication point: (1). Provided order, "the order provided in the correspondent certificate" = ---- my reading is that this would be consistent across all RPs. (2). Random order (selecting randomly from the available list) (3). RP prioritized order, "a prioritized list of URIs based on RP specific= parameters such as connection establishment delay", this may or may not be= consistent across some subset of RPs. We see the value of giving RP=92s the flexibility to choosing publications = points based on their own concerns (delay, jurisdiction, etc.). But rule (= 3) seems problematic because it could be exploited by attackers to predict = the order which an RP would fail over from one publication point to the nex= t. For example: i. An attacker could target the first publication point = of the list to distribute bad or missing objects, causing all RPs to get ba= d information. ii. An attacker who happened to compromise a publication p= oint that was not the first element of the list, could e.g. DOS publication= points at the top of the list to ensure that RPs would use the attacker=92= s publication point. iii. An attacker which could predict the fail over order cou= ld perform a rolling DOS attack attacking the first element, then the secon= d and so on. Question: Finally, there has been lots of work on fault-tolerant distributed database= systems that allow RPs to resolve inconsistencies between replicas of a da= tabase. We=92re not experts on these systems, but given that RPs will down= load RPKI data relatively infrequently, is this something that could be con= sidered here? _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --_000_24B20D14B2CD29478C8D5D6E9CBB29F67876D946HSVMB001huntsvi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The authors made a suggestion (see below) for a new course of action f= or the draft draft-ietf-sidr-multiple-publication-points, splitting the dra= ft into two work items.


And there have been nearly two months of mostly silence on the point. =  (Thanks to Steve and Arturo for their replies.).


If the working group does not reject the approach the authors suggest = by 13 Dec 2013, the authors should proceed with submission of a new version= of draft-ietf-sidr-multiple-publication-points that meets the first propos= al:


- A "6490-bis" document that obsoletes RFC 6490 with the add= ition of multiple operators in section 3 of the current document.


and submission of an individual draft for consideration of the working= group that meets the second proposal:


- A new BCP/Informational document on best practices when RPKI certifi= cates include multiple repository operators for the same materials.


--Sandy, speaking as wg co-chair

From: sidr-bounces@ietf.org [sidr-bounce= s@ietf.org] on behalf of Roque Gagliano (rogaglia) [rogaglia@cisco.com]
Sent: Monday, October 14, 2013 3:41 PM
To: sidr wg list
Subject: Re: [sidr] possible interim meeting for draft-ietf-sidr-mul= tiple-publication-points

Dear Working Group:

The co-authors of the multi-publication points document would like to = propose a new course of action to the WG referring to this document. <= /div>

Since its initial submission, the document addresses two problems rela= ted to the support of multiple operators in RPKI: 
i)-&nb= sp;Multiple Operators support in TAL files  (Section 3 of current= document)
ii)-&n= bsp;Multiple Operators support in Certificates (Section 4 of current docume= nt)

Today, we believe that the two problems are very different.  On o= ne side point i) could be quickly solved by the WG by updating or obsoletin= g RFC 6490 with the changes proposed in Section 3 of the document. We have = shown in Berlin that changes to RPs should be very small and that "some" (and I say so because in some case= s it was accidental) backward compatibility exists with most popular RPs.

However the second point ii) while it does not require changes to exis= ting standard document but rather a "BCP" document, it does requi= re much more research. While we go down to the RPKI hierarchy, we need to u= nderstand how multiple operators may create transient states and how RPs will typically react to these. Some of the qu= estions to answer were raised at the meeting and recently in the WG mailing= list.

Our proposal to the group is to split the current content in the docum= ent in two documents:  
- = ;A "6490-bis" document that obsoletes RFC 6490 with the addi= tion of multiple operators in section 3 of the current document.
- A ne= w BCP/Informational document on best practices when RPKI certificates inclu= de multiple repository operators for the same materials.

We look forward to hearing from you,
Regards,

Roque + Carlos + Terry


On Oct 2, 2013, at 9:58 AM, Roque Gagliano (rogaglia) <rogaglia@cisco.com> wrot= e:

Thanks Sharon for your email and analys= is. These points are some of the points raised during our last meeting= .

I personally believe that the non-TAL work requires more research acti= vity and I guess from your email that you have an interest in this area :-)= .

Regards,
Roque

Hi Roque,=

As you work on this, I wanted share some observations made by my colleague = here at BU, Ethan Heilman. He read the draft in detail and had a two sugges= tions and one question, see below.

Sharon

 

Suggestion 1:

 

Section 4.1 of the draft says: =93If the connection to the preferred URI = fails, the RP SHOULD fetch the repository objects from the next URI of preference."

 

We suggest that the failover logic be exte= nded to include validation failures as well as connection failures (similar t= o the logic for TALs). That is, when RPKI-validation generates a warning, a= n RP should fail over to another publication point. These warnings could be= generated by stale manifests, manifest errors (http://tools.ietf.org/html/rfc6486), expired certs, missing ROAs, and other validation failures. We call this f= ailover mode FO-Corrupt (Failover On Corruption) as opposed to the current = failover mode FO-Connect (Failover On Connection failure) in the draft.  Here=92s why we suggest FO-Corrupt:=

 

1)    &n= bsp; Multiple publication points using the FO-Connect policy increase the at= tack surface, while multiple publication points using the FO-Corrupt policy= decrease the attack surface.  With FO-Connect, corruption failures in a given publicat= ion point will directly affect RPs that select that publication point.  Meanwhile, under FO-Corrupt, a corruption failure must occur on a= ll publication points before it affects RPs; each additional publication point= adds an additional barrier to an attacker that seeks to corrupt objects. T= his also allows operators to raise the cost of an attack by adding publicat= ion points using diverse software and operating systems.  Importantly, missing or corrupte= d RPKI objects can cause routes to become classified as invalid, and theref= ore be less preferred -- I provide examples of this happening in the attach= ed PDF =96 so if some of the publication points contain uncorrupted objects, it=92s important to ensure that RP=92s= fetch them.

 

2)    &n= bsp; The differences in behavior between TAL failover and RPKI object failov= er could cause confusion.    FO-Corrupt would provide a more consistent = policy.   Compare the quote from Section 4.1 above with the following from Section 3.2:          =93If the connection to the preferred URI fails or= the fetched certificate public key does not match the TAL public key,= the RP SHOULD fetch the TA certificate from the next URI of preferenc= e.=94
 
Suggestion 2:

 

Section 3.2 and 4.1 of the draft sug= gest three rules to select the URI of the publication point:
(1). Provided order, "the order provided in the correspondent cer= tificate" ---- my reading is that  this would be consistent across all RPs.
(2). Random order (selecting randoml= y from the available list)
(3). RP prioritized order, = ;"a prioritized list of URIs based on RP specific parameters such= as connection establishment delay", this may or may not be consi= stent across some subset of RPs. 

 

We see the value of giving RP=92s th= e flexibility to choosing publications points based on their own concerns (= delay, jurisdiction, etc.).  But rule (3) seems problematic because it could be = exploited by attackers to predict the order which an RP would fail over fro= m one publication point to the next. For example:
i.    &n= bsp;            = ;   An attacker could target the first publication point of the list <= /span>to distribute bad or missing obje= cts, causing all RPs to get bad information.
ii.    &n= bsp;            = ; An attacker who happened to compromise a publication point that was not= the first element of the list, could e.g. DOS publication points at the to= p of the list to ensure that RPs would use the attacker=92s publication point.  
iii.    &= nbsp;           An attacker which could predict the fail over order could perform a rol= ling DOS attack attacking the first element, then the second and so on.

 

Question: 
 
Finally, there has been lots of work= on fault-tolerant distributed database systems that allow RPs to resolve i= nconsistencies between replicas of a database.  We=92re not experts on these systems, but given that RPs will downlo= ad RPKI data relatively infrequently, is this something that could be consi= dered here?
<examples.pdf>

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

--_000_24B20D14B2CD29478C8D5D6E9CBB29F67876D946HSVMB001huntsvi_-- From internet-drafts@ietf.org Tue Dec 10 15:26:40 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF2A1AE2A6; Tue, 10 Dec 2013 15:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uno5nPB99jiK; Tue, 10 Dec 2013 15:26:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 515EB1AD943; Tue, 10 Dec 2013 15:26:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131210232638.7289.43037.idtracker@ietfa.amsl.com> Date: Tue, 10 Dec 2013 15:26:38 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 23:26:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Threat Model for BGP Path Security Author(s) : Stephen Kent Andrew Chi Filename : draft-ietf-sidr-bgpsec-threats-09.txt Pages : 20 Date : 2013-12-10 Abstract: This document describes a threat model for the context in which Exterior Border Gateway Protocol (EBGP) path security mechanisms will be developed. The threat model includes an analysis of the Resource Public Key Infrastructure (RPKI), and focuses on the ability of an autonomous system (AS) to verify the authenticity of the AS path info received in a BGP update. We use the term PATHSEC to refer to any BGP path security technology that makes use of the RPKI. PATHSEC will secure BGP, consistent with the inter-AS security focus of the RPKI. The document characterizes classes of potential adversaries that are considered to be threats, and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in the BGP-4 standard. It concludes with brief discussion of residual vulnerabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-threats-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From achi@cs.unc.edu Tue Dec 10 15:33:32 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237731ADBD2 for ; Tue, 10 Dec 2013 15:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb3q02hMCX1T for ; Tue, 10 Dec 2013 15:33:29 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 49CBB1AD845 for ; Tue, 10 Dec 2013 15:33:29 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id id10so5025635vcb.5 for ; Tue, 10 Dec 2013 15:33:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=kenbWm6BMLmDeJ+V8U+VWDmC726pddtmCUFVQed/3eQ=; b=L14CVt3eJ71aH5mRBnrpux6HsIzszpOs3m0Mv86pjWOUzSe66eZMndddKoR0izeqz3 sO4mH36VJxZ6po9xpgYbNYA2yT0xPJ3om3jAT754K2qdqHBxNR8eOhHEjHWKjslaj24b hRTJmF1UC9YqUS/7fM+h7RIRLP5jpSf1m9cBKfbnEO+BiH6hVCum63WcTqIIepi/dgCC OFCMVstsYuPzw1Bp3HTCxXsauqUYPmYSKkpaOSr9zk4MsvMge5TLVxfOYSdDztDDlCOe RtrWrJOYZE8SJ79a5bFP1DpcrttLecpgZOmq7H+j+1BVXx4Pqw/JHFNaR5CdNMcglmlB eM8g== X-Gm-Message-State: ALoCoQkGmMkBrYfkkU/B7vTFVe6B15vdsskAg2DjBR4J4JYdSEnLMOdA3jR2Z2fr6yvzEATcLSn1 MIME-Version: 1.0 X-Received: by 10.220.127.68 with SMTP id f4mr1165933vcs.32.1386718403727; Tue, 10 Dec 2013 15:33:23 -0800 (PST) Received: by 10.52.96.170 with HTTP; Tue, 10 Dec 2013 15:33:23 -0800 (PST) In-Reply-To: <20131210232638.7289.61933.idtracker@ietfa.amsl.com> References: <20131210232638.7289.61933.idtracker@ietfa.amsl.com> Date: Tue, 10 Dec 2013 18:33:23 -0500 Message-ID: From: Andrew Chi To: sidr@ietf.org Content-Type: multipart/alternative; boundary=047d7b3439b8dbaa8a04ed368921 Subject: [sidr] Fwd: New Version Notification - draft-ietf-sidr-bgpsec-threats-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 23:33:32 -0000 --047d7b3439b8dbaa8a04ed368921 Content-Type: text/plain; charset=UTF-8 This revision addresses Stephen Farrell's comments (thanks). ---------- Forwarded message ---------- From: Date: Tue, Dec 10, 2013 at 6:26 PM Subject: New Version Notification - draft-ietf-sidr-bgpsec-threats-09.txt A new version (-09) has been submitted for draft-ietf-sidr-bgpsec-threats: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-threats-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-threats-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. --047d7b3439b8dbaa8a04ed368921 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This revision addresses Stephen Farrell's comments (th= anks).

---------- Forwarded message -----= -----
From: <internet-drafts@ietf.org>
Date: Tue, Dec 10, 2013 at 6:26 PM
Subject: New Version Notification - d= raft-ietf-sidr-bgpsec-threats-09.txt


A new version (-09) has been submitted for draft-ietf-sidr-bgpsec-threats:<= br> http://www.ietf.org/internet-drafts/draft-ietf= -sidr-bgpsec-threats-09.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec= -threats/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-= bgpsec-threats-09

Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.


--047d7b3439b8dbaa8a04ed368921-- From internet-drafts@ietf.org Wed Dec 11 09:03:56 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043781AE0B8; Wed, 11 Dec 2013 09:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9Vi7oJ4PeDi; Wed, 11 Dec 2013 09:03:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF24B1AE029; Wed, 11 Dec 2013 09:03:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131211170354.23464.95472.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 09:03:54 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-oob-setup-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 17:03:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : An Out-Of-Band Setup Protocol For RPKI Production Servic= es Author(s) : Rob Austein Filename : draft-ietf-sidr-rpki-oob-setup-00.txt Pages : 19 Date : 2013-12-11 Abstract: This note describes a simple out-of-band protocol to ease setup of the RPKI provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable secure means. This setup protocol is not part of the provisioning or publication protocol, rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging BPKI keying material. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-oob-setup-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sra@hactrn.net Wed Dec 11 09:13:40 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964151ACB4E for ; Wed, 11 Dec 2013 09:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxuDx11fe3Qn for ; Wed, 11 Dec 2013 09:13:39 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7D29C1AC403 for ; Wed, 11 Dec 2013 09:13:39 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [10.0.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id D6DEF73045 for ; Wed, 11 Dec 2013 17:13:31 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 7311C17138 for ; Wed, 11 Dec 2013 12:13:31 -0500 (EST) Date: Wed, 11 Dec 2013 12:13:31 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20131211170354.23464.95472.idtracker@ietfa.amsl.com> References: <20131211170354.23464.95472.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20131211171331.7311C17138@thrintun.hactrn.net> Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-oob-setup-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 17:13:40 -0000 Resubmission as WG draft, no substantive changes from draft-austein-sidr-rpki-oob-setup-00. From internet-drafts@ietf.org Thu Dec 12 08:23:12 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BB11AE346; Thu, 12 Dec 2013 08:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqWpUfwrAi4z; Thu, 12 Dec 2013 08:23:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9981ADFB7; Thu, 12 Dec 2013 08:23:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131212162310.12789.30997.idtracker@ietfa.amsl.com> Date: Thu, 12 Dec 2013 08:23:10 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-impl-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 16:23:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : RPKI Router Implementation Report Author(s) : Randy Bush Rob Austein Keyur Patel Hannes Gredler Matthias Waehlisch Filename : draft-ietf-sidr-rpki-rtr-impl-05.txt Pages : 11 Date : 2013-12-12 Abstract: This document is an implementation report for the RPKI Router protocol as defined in [RFC6810]. The editor did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-impl There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-impl-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpki-rtr-impl-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sra@hactrn.net Thu Dec 12 10:21:01 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32951AE0BE for ; Thu, 12 Dec 2013 10:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7XTn6ivWwvl for ; Thu, 12 Dec 2013 10:21:00 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id 517F61AE00E for ; Thu, 12 Dec 2013 10:21:00 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 429FD73046 for ; Thu, 12 Dec 2013 18:20:53 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C59B61713D for ; Thu, 12 Dec 2013 13:20:52 -0500 (EST) Date: Thu, 12 Dec 2013 13:20:52 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20131212162310.12789.30997.idtracker@ietfa.amsl.com> References: <20131212162310.12789.30997.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20131212182052.C59B61713D@thrintun.hactrn.net> Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-impl-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 18:21:01 -0000 This I-D passed the IESG last week, with a few minor clarifications requested; this revision attempts to address those. For details, see: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-impl From internet-drafts@ietf.org Mon Dec 16 07:20:06 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05131AE346; Mon, 16 Dec 2013 07:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yrbc7drg-OUK; Mon, 16 Dec 2013 07:20:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AC21ADE8A; Mon, 16 Dec 2013 07:20:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131216152000.13310.69212.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2013 07:20:00 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 15:20:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : An Overview of BGPSEC Author(s) : Matt Lepinski Sean Turner Filename : draft-ietf-sidr-bgpsec-overview-04.txt Pages : 10 Date : 2013-12-16 Abstract: This document provides an overview of a security extension to the Border Gateway Protocol (BGP) referred to as BGPSEC. BGPSEC improves security for BGP routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-overview There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-overview-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-overview-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From e.hall@snsreports.com Tue Dec 17 02:15:25 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C3B1AE13E for ; Tue, 17 Dec 2013 02:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.9 X-Spam-Level: * X-Spam-Status: No, score=1.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTxbW8eA5wyu for ; Tue, 17 Dec 2013 02:15:22 -0800 (PST) Received: from 220-190.sl.smtp.com (220-190.sl.smtp.com [192.40.190.220]) by ietfa.amsl.com (Postfix) with ESMTP id 439761AE146 for ; Tue, 17 Dec 2013 02:15:22 -0800 (PST) X-MSFBL: c2lkckBpZXRmLm9yZ0AxOTJfNDBfMTkwXzIyMEBTbnN0ZWxlY29tX2RlZGljYXRl ZF9wb29sQA== DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple; q=dns/txt; i=@smtp.com; t=1387275321; h=From:Subject:To:Date:MIME-Version:Content-Type; bh=8q8GrNfaI4AxXGM1zuHeDcjnUn0Y53UX4yJfNXHBY3M=; b=kZ1bHCVWBfhD4+1EKRl1QK+CkbIvxAwU6srMpB9UU0s2gXRg0pTxJdQZqsLHDqjs LsUBIC5m7gmENwmpLkik4f+7duDIxmoeN5BsNG95YXpDfmX3jUTN1n0HwBzxt5nb ax4+PAJfNwzlwln0wOqdm8GplpWwgZ4bQPXHvTERg10=; Received: from [92.24.85.179] ([92.24.85.179:21125] helo=host-92-24-85-179.ppp.as43234.net) by sl-mta04 (envelope-from ) (ecelerity 3.3.2.44647 r(44647)) with ESMTPA id AD/15-02611-83420B25; Tue, 17 Dec 2013 10:15:21 +0000 MIME-Version: 1.0 From: "Signals & Systems Telecom" To: sidr@ietf.org Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Smart_Send_2_0_132 Date: Tue, 17 Dec 2013 10:15:14 +0000 Message-ID: <1036242349464594023636@Owner-PC> X-SMTPCOM-Tracking-Number: b013d554-35bd-4bb7-b393-12dfa90b05b4 X-SMTPCOM-Sender-ID: 6005703 X-SMTPCOM-Spam-Policy: SMTP.com is a paid relay service. We do not tolerate UCE of any kind. Please report it ASAP to abuse@smtp.com Subject: [sidr] The Wireless Network Infrastructure Bible: 2014 - 2020 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: e.hall@snsreports.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 10:15:25 -0000

The Wireless= Network Infrastructure Bible: 2014 =96 2020 - Macrocell RAN, Small Cells, = RRH, DAS, Cloud RAN, Carrier WiFi, Mobile Core & Backhaul

=

Hello, 

= Hope you are doing well. 

The Wireles= s Network Infrastructure Bible: 2014 =96 2020 - Macrocell RAN, Small Cells,= RRH, DAS, Cloud RAN, Carrier WiFi, Mobile Core & Backhaul."

=

= Repor= t Information:

Number of Pages: 391
Number of Tables and Figures: 450

= Repor= t Overview:

 

Key Findings:

<= /B>
The report has the fol= lowing key findings:
  • Between 2014 and 2020, the 2G, 3G & 4G wireless network infr= astructure market is expected to grow at a CAGR of nearly 5%<= /LI>
  • Vendors are increasing their focus on profit margins. Many are a= lready cutting staff, embracing operational excellence, evolving their new = business models, acquiring niche businesses and expanding their managed ser= vices offerings
  • New CapEx commitment avenues such as HetNet infrastructure and v= irtualization will usher industry restructuring. The wireless network infra= structure market will consolidate so as to eliminate one of the current glo= bal players by 2020
  • As wireless carriers look to offload traffic from their overburd= ened macrocell infrastructure, HetNet infrastructure will represent a marke= t worth $43 Billion in 2020
  • Operators will ramp up on backhaul, aggregation, transport, rout= ing based on IP and Ethernet technologies for offering mobile broadband ser= vices
  • Developing market growth will be a significant factor during the= forecast period, with China and India seeing some of the highest levels of= growth, both in terms of shipments and in the size of their installed base= . After 2014, developing countries and their requirements will begin to sha= pe future infrastructure technologies and architectures
  • Due to the investments in a single RAN technology, future LTE in= vestments will cost much less than early investments of the technology
  • Supplemented with a drive towards virtualization, a limited amou= nt of hardware installation will be needed when wireless carriers upgrade t= o LTE in the future
  • From 2016 onwards wireless carriers and vendors will spend at le= ast $1 Billion per annum in R&D spending to drive standardization and c= ommercialization of 5G technology
  • Voice over LTE (VoLTE) subscriptions will surpass 700 Million by= 2020

Topics Covered:<= /FONT>

<= /B>
The report covers the = following topics:
  • Up-to-date coverage of market dynamics allowing wireless network= infrastructure vendors to analyze the opportunities and challenges of sell= ing to wireless carriers in different regional markets
  • Analysis of demand and supply of wireless infrastructure and the= strategies of the key vendors. Research includes quantitative and qualitat= ive market assessments as well as the forecasts of market trends, technolog= y requirements and deployment strategies
  • Market analysis and forecasts for 9 individual submarkets and th= eir subcategories: macrocell Radio Access Network (RAN), mobile core, macro= cell backhaul, Remote Radio Heads (RRH), Distributed Antenna Systems (DAS),= small cell RAN, cloud RAN, small cell backhaul and carrier WiFi
  • Exclusive interview transcripts from 2 of the largest wireless n= etwork infrastructure vendors; Ericsson and NSN
  • Mobile network CapEx commitments per region 
  • Mobile network subscriptions, traffic projections and service re= venue by technology and region
  • An assessment of 5G technology, initiatives and R&D commitme= nts

Historical Revenue = & Forecast Segmentation:
Market forecasts and h= istorical revenue/unit shipment figures are provided for each of the follow= ing submarkets and their subcategories: 
  • Submarkets
    • Macrocell RAN
    • Small Cell RAN
    • Remote Radio Heads (RRH)
    • Distributed Antenna Systems (DAS)
    • Cloud RAN
    • Carrier WiFi
    • Mobile Core
    • Macrocell Backhaul
    • Small Cell Backhaul
The following regional and t= echnology markets are also covered:
  • Regional Markets
    • Asia Pacific
    • Eastern Europe
    • Latin & Central America
    • Middle East & Africa
    • North America
    • Western Europe
  • Technology Markets
    • GSM
    • CDMA/CDMA2000/EV-DO
    • W-CDMA/HSPA
    • LTE FDD
    • TD-LTE
    • WiMAX
    • WiFi
Key Questions An= swered:

<= /B>
The report provides an= swers to the following key questions:
  • What are the key market drivers and challenges for SDN, NFV and = the wider network virtualization ecosystem=3F
  • How is the 2G, 3G & 4G wireless infrastructure market evolvi= ng by segment and region=3F What will the market size be in 2020 and at wha= t rate will it grow=3F
  • What trends, challenges and barriers are influencing its growth= =3F
  • How will the market shape for small cell infrastructure and othe= r HetNet deployments such as DAS and cloud RAN=3F
  • How will WiFi fit into future mobile network architectures for a= ccess and offload=3F
  • Who are the key vendors in the market, what is their market shar= e and what are their strategies=3F
  • What strategies should be adopted by wireless carriers and infra= structure vendors to remain a dominant market force=3F
  • Which 2G, 3G & 4G technology constitutes the highest amount = of spending and how will this evolve overtime=3F
  • How will LTE deployments proceed, and how long will GSM, HSPA an= d CDMA technologies co-exist with LTE=3F
  • When will WiMAX infrastructure spending diminish=3F
  • What is the global and regional outlook for each individual sub-= market including macrocell RAN, small cells, RRH, DAS, cloud RAN, carrier W= iFi, mobile core, macrocell backhaul and small cell backhaul=3F
  • What is the opportunity for the mobile backhaul market, and what= new backhaul solutions are evolving=3F
  • Do emerging virtualization technologies such as Network Function= s Virtualization (NFV) pose a threat to traditional wireless infrastructure= vendors=3F
  • How much will vendors and operators invest in 5G R&D=3F
  • How low is the Total Cost of Ownership (TCO) of a HetNet deploym= ent in comparison to a homogeneous macrocell only RAN network=3F

= Repor= t Pricing:

= Single User= License: USD 2,500

= Company Wid= e License: USD 3,500

= Order= ing Process:

=
P= lease contact Emily Hall at e.hall@snsreports.com

= And provide= the following information:
Report Title:
Report License (Single User= /Company Wide):
Name:
Email:
Job Title:
Company:
Invoice Add= ress:

= Please = ;contact me if you have any questions, or wish to purchase a copy.

= I look forw= ard to hearing from you.

= Kind Regard= s,

= Emily Hall<= /FONT>

Sales Director

Signals and Systems Telecom

Email: e.hall@snsreports.com

Address: Reef Tower
Jumeirah Lake Towers
Sheikh Zayed RoadDubai, UAE

www.snstelecom.com

 

<= FONT face=3DVerdana,Arial,Helvetica,sans-serif>To unsubscribe please click = on the link below or send an email with unsubscribe in the subject line to:=  unsubcribe@snsreports.com

<= A style=3D"COLOR: rgb(17,85,204)" href=3D"mailto:unsubscribe@snsreports.com= =3Fsubject=3DUnsubscribe" target=3D_blank>Remove=

From prvs=5063a22dbb=sandra.murphy@parsons.com Tue Dec 17 07:36:09 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC911AE173 for ; Tue, 17 Dec 2013 07:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7A_VSOypZ8u for ; Tue, 17 Dec 2013 07:36:06 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 8E48E1ADF62 for ; Tue, 17 Dec 2013 07:36:06 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id rBHFZF3v000504 for ; Tue, 17 Dec 2013 09:36:05 -0600 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1gtjgd9nep-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Dec 2013 09:36:04 -0600 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id rBHFa3mT012824 for ; Tue, 17 Dec 2013 09:36:03 -0600 Received: from kraven.huntsville.ads.sparta.com (kraven.huntsville.sparta.com [10.62.8.137]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id rBHFZwN9024522 for ; Tue, 17 Dec 2013 09:36:03 -0600 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by kraven.huntsville.ads.sparta.com ([::1]) with mapi id 14.02.0342.003; Tue, 17 Dec 2013 09:35:58 -0600 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: a query to the wg regarding publication draft Thread-Index: AQHO3IXON5REMGrzckWEdHA42xLww5pGgOZHgBJBJ+w= Date: Tue, 17 Dec 2013 15:35:56 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F67876F008@HSV-MB001.huntsville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F678760F25@HSV-MB002.huntsville.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F67876D91D@HSV-MB001.huntsville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F67876D91D@HSV-MB001.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2013-12-17_03:2013-12-17,2013-12-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=110.568 compositescore=0.0527339388916443 urlsuspect_oldscore=0.527339388916442 suspectscore=0 recipient_domain_to_sender_totalscore=1469 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=7945 rbsscore=0.0527339388916443 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312170088 Subject: Re: [sidr] a query to the wg regarding publication draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 15:36:09 -0000 No replies, so the author(s) should take the action they think best.=0A= =0A= --Sandy, speaking as co-chair=0A= ________________________________________=0A= From: sidr [sidr-bounces@ietf.org] on behalf of Murphy, Sandra [Sandra.Murp= hy@parsons.com]=0A= Sent: Thursday, December 05, 2013 7:52 PM=0A= To: sidr@ietf.org=0A= Subject: Re: [sidr] a query to the wg regarding publication draft=0A= =0A= There have been few replies to this message (thanks to Steve and Tim for th= eir replies), perhaps because there's no deadline set to urge action.=0A= =0A= Please do respond to the list by 13 Dec with your thoughts on Rob's questio= n.=0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@parsons.com]=0A= Sent: Friday, November 08, 2013 8:25 AM=0A= To: sidr@ietf.org=0A= Subject: [sidr] a query to the wg regarding publication draft=0A= =0A= Rob posed a question to the room during the meeting on Tue (Nov 5) about th= e publication draft. See slides at http://www.ietf.org/proceedings/88/slid= es/slides-88-sidr-1.pdf.=0A= =0A= The question to the list is:=0A= =0A= Should the protocol be trimmed -- take out all of the =93control=94 operati= ons, leaving just the and operations -- or should th= e "control" operations be an optional sub-protocol?=0A= =0A= What say ye?=0A= =0A= --Sandy=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From prvs=5063a22dbb=sandra.murphy@parsons.com Tue Dec 17 08:18:00 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2581AE1CE for ; Tue, 17 Dec 2013 08:18:00 -0800 (PST) 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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpUh7NLR9v2w for ; Tue, 17 Dec 2013 08:17:57 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB491AE1C0 for ; Tue, 17 Dec 2013 08:17:57 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id rBHGFLZR009449; Tue, 17 Dec 2013 10:17:39 -0600 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1gtsnrr47w-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 17 Dec 2013 10:17:38 -0600 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id rBHGHbad013180; Tue, 17 Dec 2013 10:17:37 -0600 Received: from HSV-CAS003.huntsville.ads.sparta.com ([10.62.8.138]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id rBHGHWmK026822; Tue, 17 Dec 2013 10:17:32 -0600 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by HSV-CAS003.huntsville.ads.sparta.com ([fe80::a415:ede2:34ef:d13f%11]) with mapi id 14.02.0342.003; Tue, 17 Dec 2013 10:17:32 -0600 From: "Murphy, Sandra" To: "Roque Gagliano (rogaglia)" , sidr wg list Thread-Topic: [sidr] a new direction for draft-ietf-sidr-multiple-publication-points Thread-Index: AQHO8h8xkWqxlIUeVEKSk3p4x8e5kppYlyYY Date: Tue, 17 Dec 2013 16:17:30 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F67876F01E@HSV-MB001.huntsville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F67876D946@HSV-MB001.huntsville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F67876D946@HSV-MB001.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F67876F01EHSVMB001huntsvi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2013-12-17_03:2013-12-17,2013-12-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=139.659774022444 compositescore=0.00548233407741067 urlsuspect_oldscore=0.475211685653588 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=5 recipient_domain_to_sender_domain_totalscore=12528 rbsscore=0.00548233407741067 spamscore=0 recipient_to_sender_domain_totalscore=5 urlsuspectscore=0.1 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312170098 Subject: Re: [sidr] a new direction for draft-ietf-sidr-multiple-publication-points X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 16:18:01 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F67876F01EHSVMB001huntsvi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No replies, so the authors should proceed as suggested. --Sandy, speaking as co-chair ________________________________ From: sidr [sidr-bounces@ietf.org] on behalf of Murphy, Sandra [Sandra.Murp= hy@parsons.com] Sent: Thursday, December 05, 2013 8:05 PM To: Roque Gagliano (rogaglia); sidr wg list Subject: [sidr] a new direction for draft-ietf-sidr-multiple-publication-po= ints The authors made a suggestion (see below) for a new course of action for th= e draft draft-ietf-sidr-multiple-publication-points, splitting the draft in= to two work items. And there have been nearly two months of mostly silence on the point. (Tha= nks to Steve and Arturo for their replies.). If the working group does not reject the approach the authors suggest by 13= Dec 2013, the authors should proceed with submission of a new version of d= raft-ietf-sidr-multiple-publication-points that meets the first proposal: - A "6490-bis" document that obsoletes RFC 6490 with the addition of multip= le operators in section 3 of the current document. and submission of an individual draft for consideration of the working grou= p that meets the second proposal: - A new BCP/Informational document on best practices when RPKI certificates= include multiple repository operators for the same materials. --Sandy, speaking as wg co-chair ________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Roque Gagl= iano (rogaglia) [rogaglia@cisco.com] Sent: Monday, October 14, 2013 3:41 PM To: sidr wg list Subject: Re: [sidr] possible interim meeting for draft-ietf-sidr-multiple-p= ublication-points Dear Working Group: The co-authors of the multi-publication points document would like to propo= se a new course of action to the WG referring to this document. Since its initial submission, the document addresses two problems related t= o the support of multiple operators in RPKI: i)- Multiple Operators support in TAL files (Section 3 of current document= ) ii)- Multiple Operators support in Certificates (Section 4 of current docum= ent) Today, we believe that the two problems are very different. On one side po= int i) could be quickly solved by the WG by updating or obsoleting RFC 6490= with the changes proposed in Section 3 of the document. We have shown in B= erlin that changes to RPs should be very small and that "some" (and I say s= o because in some cases it was accidental) backward compatibility exists wi= th most popular RPs. However the second point ii) while it does not require changes to existing = standard document but rather a "BCP" document, it does require much more re= search. While we go down to the RPKI hierarchy, we need to understand how m= ultiple operators may create transient states and how RPs will typically re= act to these. Some of the questions to answer were raised at the meeting an= d recently in the WG mailing list. Our proposal to the group is to split the current content in the document i= n two documents: - A "6490-bis" document that obsoletes RFC 6490 with the addition of multip= le operators in section 3 of the current document. - A new BCP/Informational document on best practices when RPKI certificates= include multiple repository operators for the same materials. We look forward to hearing from you, Regards, Roque + Carlos + Terry On Oct 2, 2013, at 9:58 AM, Roque Gagliano (rogaglia) > wrote: Thanks Sharon for your email and analysis. These points are some of the poi= nts raised during our last meeting. I personally believe that the non-TAL work requires more research activity = and I guess from your email that you have an interest in this area :-). Regards, Roque Hi Roque, As you work on this, I wanted share some observations made by my colleague = here at BU, Ethan Heilman. He read the draft in detail and had a two sugges= tions and one question, see below. Sharon Suggestion 1: Section 4.1 of the draft says: =93If the connection to the preferred URI fa= ils, the RP SHOULD fetch the repository objects from the next URI of prefer= ence." We suggest that the failover logic be extended to include validation failur= es as well as connection failures (similar to the logic for TALs). That is,= when RPKI-validation generates a warning, an RP should fail over to anothe= r publication point. These warnings could be generated by stale manifests, = manifest errors (http://tools.ietf.org/html/rfc6486), expired certs, miss= ing ROAs, and other validation failures. We call this failover mode FO-Corr= upt (Failover On Corruption) as opposed to the current failover mode FO-Con= nect (Failover On Connection failure) in the draft. Here=92s why we sugges= t FO-Corrupt: 1) Multiple publication points using the FO-Connect policy increase th= e attack surface, while multiple publication points using the FO-Corrupt po= licy decrease the attack surface. With FO-Connect, corruption failures in = a given publication point will directly affect RPs that select that publica= tion point. Meanwhile, under FO-Corrupt, a corruption failure must occur o= n all publication points before it affects RPs; each additional publication= point adds an additional barrier to an attacker that seeks to corrupt obje= cts. This also allows operators to raise the cost of an attack by adding pu= blication points using diverse software and operating systems. Importantly= , missing or corrupted RPKI objects can cause routes to become classified a= s invalid, and therefore be less preferred -- I provide examples of this ha= ppening in the attached PDF =96 so if some of the publication points contai= n uncorrupted objects, it=92s important to ensure that RP=92s fetch them. 2) The differences in behavior between TAL failover and RPKI object fa= ilover could cause confusion. FO-Corrupt would provide a more consistent= policy. Compare the quote from Section 4.1 above with the following from= Section 3.2: =93If the connection to the preferred URI fails or t= he fetched certificate public key does not match the TAL public key, the RP= SHOULD fetch the TA certificate from the next URI of preference.=94 Suggestion 2: Section 3.2 and 4.1 of the draft suggest three rules to select the URI of t= he publication point: (1). Provided order, "the order provided in the correspondent certificate" = ---- my reading is that this would be consistent across all RPs. (2). Random order (selecting randomly from the available list) (3). RP prioritized order, "a prioritized list of URIs based on RP specific= parameters such as connection establishment delay", this may or may not be= consistent across some subset of RPs. We see the value of giving RP=92s the flexibility to choosing publications = points based on their own concerns (delay, jurisdiction, etc.). But rule (= 3) seems problematic because it could be exploited by attackers to predict = the order which an RP would fail over from one publication point to the nex= t. For example: i. An attacker could target the first publication point = of the list to distribute bad or missing objects, causing all RPs to get ba= d information. ii. An attacker who happened to compromise a publication p= oint that was not the first element of the list, could e.g. DOS publication= points at the top of the list to ensure that RPs would use the attacker=92= s publication point. iii. An attacker which could predict the fail over order cou= ld perform a rolling DOS attack attacking the first element, then the secon= d and so on. Question: Finally, there has been lots of work on fault-tolerant distributed database= systems that allow RPs to resolve inconsistencies between replicas of a da= tabase. We=92re not experts on these systems, but given that RPs will down= load RPKI data relatively infrequently, is this something that could be con= sidered here? _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --_000_24B20D14B2CD29478C8D5D6E9CBB29F67876F01EHSVMB001huntsvi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
No replies, so the authors should proceed as suggested.

--Sandy, speaking as co-chair
From: sidr [sidr-bounces@ietf.org] on be= half of Murphy, Sandra [Sandra.Murphy@parsons.com]
Sent: Thursday, December 05, 2013 8:05 PM
To: Roque Gagliano (rogaglia); sidr wg list
Subject: [sidr] a new direction for draft-ietf-sidr-multiple-publica= tion-points

The authors made a suggestion (see below) for a new course of action f= or the draft draft-ietf-sidr-multiple-publication-points, splitting the dra= ft into two work items.


And there have been nearly two months of mostly silence on the point. =  (Thanks to Steve and Arturo for their replies.).


If the working group does not reject the approach the authors suggest = by 13 Dec 2013, the authors should proceed with submission of a new version= of draft-ietf-sidr-multiple-publication-points that meets the first propos= al:


- A "6490-bis" document that obsoletes RFC 6490 with the add= ition of multiple operators in section 3 of the current document.


and submission of an individual draft for consideration of the working= group that meets the second proposal:


- A new BCP/Informational document on best practices when RPKI certifi= cates include multiple repository operators for the same materials.


--Sandy, speaking as wg co-chair

From: sidr-bounces@ietf.org [sidr-bounces@i= etf.org] on behalf of Roque Gagliano (rogaglia) [rogaglia@cisco.com]
Sent: Monday, October 14, 2013 3:41 PM
To: sidr wg list
Subject: Re: [sidr] possible interim meeting for draft-ietf-sidr-mul= tiple-publication-points

Dear Working Group:

The co-authors of the multi-publication points document would like to = propose a new course of action to the WG referring to this document. <= /div>

Since its initial submission, the document addresses two problems rela= ted to the support of multiple operators in RPKI: 
i)-&nb= sp;Multiple Operators support in TAL files  (Section 3 of current= document)
ii)-&n= bsp;Multiple Operators support in Certificates (Section 4 of current docume= nt)

Today, we believe that the two problems are very different.  On o= ne side point i) could be quickly solved by the WG by updating or obsoletin= g RFC 6490 with the changes proposed in Section 3 of the document. We have = shown in Berlin that changes to RPs should be very small and that "some" (and I say so because in some case= s it was accidental) backward compatibility exists with most popular RPs.

However the second point ii) while it does not require changes to exis= ting standard document but rather a "BCP" document, it does requi= re much more research. While we go down to the RPKI hierarchy, we need to u= nderstand how multiple operators may create transient states and how RPs will typically react to these. Some of the qu= estions to answer were raised at the meeting and recently in the WG mailing= list.

Our proposal to the group is to split the current content in the docum= ent in two documents:  
- = ;A "6490-bis" document that obsoletes RFC 6490 with the addi= tion of multiple operators in section 3 of the current document.
- A ne= w BCP/Informational document on best practices when RPKI certificates inclu= de multiple repository operators for the same materials.

We look forward to hearing from you,
Regards,

Roque + Carlos + Terry


On Oct 2, 2013, at 9:58 AM, Roque Gagliano (rogaglia) <rogaglia@cisco.com> wrot= e:

Thanks Sharon for your email and analys= is. These points are some of the points raised during our last meeting= .

I personally believe that the non-TAL work requires more research acti= vity and I guess from your email that you have an interest in this area :-)= .

Regards,
Roque

Hi Roque,=

As you work on this, I wanted share some observations made by my colleague = here at BU, Ethan Heilman. He read the draft in detail and had a two sugges= tions and one question, see below.

Sharon

 

Suggestion 1:

 

Section 4.1 of the draft says: =93If the connection to the preferred URI = fails, the RP SHOULD fetch the repository objects from the next URI of preference."

 

We suggest that the failover logic be exte= nded to include validation failures as well as connection failures (similar t= o the logic for TALs). That is, when RPKI-validation generates a warning, a= n RP should fail over to another publication point. These warnings could be= generated by stale manifests, manifest errors (http://tools.ietf.org/html/rfc6486), expired certs, missing ROAs, and other validation failures. We call this f= ailover mode FO-Corrupt (Failover On Corruption) as opposed to the current = failover mode FO-Connect (Failover On Connection failure) in the draft.  Here=92s why we suggest FO-Corrupt:=

 

1)    &n= bsp; Multiple publication points using the FO-Connect policy increase the at= tack surface, while multiple publication points using the FO-Corrupt policy= decrease the attack surface.  With FO-Connect, corruption failures in a given publicat= ion point will directly affect RPs that select that publication point.  Meanwhile, under FO-Corrupt, a corruption failure must occur on a= ll publication points before it affects RPs; each additional publication point= adds an additional barrier to an attacker that seeks to corrupt objects. T= his also allows operators to raise the cost of an attack by adding publicat= ion points using diverse software and operating systems.  Importantly, missing or corrupte= d RPKI objects can cause routes to become classified as invalid, and theref= ore be less preferred -- I provide examples of this happening in the attach= ed PDF =96 so if some of the publication points contain uncorrupted objects, it=92s important to ensure that RP=92s= fetch them.

 

2)    &n= bsp; The differences in behavior between TAL failover and RPKI object failov= er could cause confusion.    FO-Corrupt would provide a more consistent = policy.   Compare the quote from Section 4.1 above with the following from Section 3.2:          =93If the connection to the preferred URI fails or= the fetched certificate public key does not match the TAL public key,= the RP SHOULD fetch the TA certificate from the next URI of preferenc= e.=94
 
Suggestion 2:

 

Section 3.2 and 4.1 of the draft sug= gest three rules to select the URI of the publication point:
(1). Provided order, "the order provided in the correspondent cer= tificate" ---- my reading is that  this would be consistent across all RPs.
(2). Random order (selecting randoml= y from the available list)
(3). RP prioritized order, = ;"a prioritized list of URIs based on RP specific parameters such= as connection establishment delay", this may or may not be consi= stent across some subset of RPs. 

 

We see the value of giving RP=92s th= e flexibility to choosing publications points based on their own concerns (= delay, jurisdiction, etc.).  But rule (3) seems problematic because it could be = exploited by attackers to predict the order which an RP would fail over fro= m one publication point to the next. For example:
i.    &n= bsp;            = ;   An attacker could target the first publication point of the list <= /span>to distribute bad or missing obje= cts, causing all RPs to get bad information.
ii.    &n= bsp;            = ; An attacker who happened to compromise a publication point that was not= the first element of the list, could e.g. DOS publication points at the to= p of the list to ensure that RPs would use the attacker=92s publication point.  
iii.    &= nbsp;           An attacker which could predict the fail over order could perform a rol= ling DOS attack attacking the first element, then the second and so on.

 

Question: 
 
Finally, there has been lots of work= on fault-tolerant distributed database systems that allow RPs to resolve i= nconsistencies between replicas of a database.  We=92re not experts on these systems, but given that RPs will downlo= ad RPKI data relatively infrequently, is this something that could be consi= dered here?
<examples.pdf>

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

--_000_24B20D14B2CD29478C8D5D6E9CBB29F67876F01EHSVMB001huntsvi_-- From internet-drafts@ietf.org Tue Dec 17 12:52:28 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C0E1ADFDD; Tue, 17 Dec 2013 12:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Rl5gi3o7P0S; Tue, 17 Dec 2013 12:52:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5659E1ADFCC; Tue, 17 Dec 2013 12:52:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131217205227.8291.94169.idtracker@ietfa.amsl.com> Date: Tue, 17 Dec 2013 12:52:27 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 20:52:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Router Keying for BGPsec Author(s) : Sean Turner Keyur Patel Randy Bush Filename : draft-ietf-sidr-rtr-keying-04.txt Pages : 8 Date : 2013-12-17 Abstract: BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global RPKI (Resource Public Key Infrastructure). This document describes two ways of provisioning public/private keys, router-driven and operator- driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sharon.goldbe@gmail.com Sun Dec 22 07:31:32 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62591ADF4F for ; Sun, 22 Dec 2013 07:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hep6Mabr575 for ; Sun, 22 Dec 2013 07:31:29 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7BABF1AE2FB for ; Sun, 22 Dec 2013 07:31:29 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id x55so4124544wes.40 for ; Sun, 22 Dec 2013 07:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=h7ezMW70vefDiCXngnybzmht6UX7HJeWlXHAHoLirog=; b=OAWILwlZyK3MmikLH16peykTnbjpLOUI2wVWNbOdPaLjykb6WViMBmX2W/UiKZGPPL qtwD2G7W1pO+2MkUSnCvuGw++wMqu6ZlQtsNeI27cRDDjH3tupnC4PmkU7jkuvbas+bX y+8NtgKOV7g7ER6PGEe25ErQNdUT2wuyKyDoJrL1HHKbnDCGOvDsTMSGwDurTLAmWRom WD4q+BlXjxjSmS5nr2F/ShlbCikZO5LVkWFkITJ42tf25EcZtRA2qpaGpx+XYXOao2zG ROuiRUHB3VhbZN1TqcLhKa8UalQn1D23aQyk1dm6usJ3Kzw288nJ1fIGhjQvcT2GLgkh KJcA== X-Received: by 10.180.38.8 with SMTP id c8mr9822361wik.48.1387726286088; Sun, 22 Dec 2013 07:31:26 -0800 (PST) MIME-Version: 1.0 Sender: sharon.goldbe@gmail.com Received: by 10.194.17.98 with HTTP; Sun, 22 Dec 2013 07:30:45 -0800 (PST) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F67876F01E@HSV-MB001.huntsville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F67876D946@HSV-MB001.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F67876F01E@HSV-MB001.huntsville.ads.sparta.com> From: Sharon Goldberg Date: Sun, 22 Dec 2013 10:30:45 -0500 X-Google-Sender-Auth: yK3_Nmg2u-IYFURUTdmcDaXwLnA Message-ID: To: sidr wg list Content-Type: multipart/alternative; boundary=e89a8f646edd53eecc04ee2134f6 Subject: Re: [sidr] a new direction for draft-ietf-sidr-multiple-publication-points X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 15:31:33 -0000 --e89a8f646edd53eecc04ee2134f6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is probably a little late, but I support this plan. Sharon On Tue, Dec 17, 2013 at 11:17 AM, Murphy, Sandra wrote: > No replies, so the authors should proceed as suggested. > > --Sandy, speaking as co-chair > ------------------------------ > *From:* sidr [sidr-bounces@ietf.org] on behalf of Murphy, Sandra [ > Sandra.Murphy@parsons.com] > *Sent:* Thursday, December 05, 2013 8:05 PM > *To:* Roque Gagliano (rogaglia); sidr wg list > *Subject:* [sidr] a new direction for > draft-ietf-sidr-multiple-publication-points > > The authors made a suggestion (see below) for a new course of action > for the draft draft-ietf-sidr-multiple-publication-points, splitting the > draft into two work items. > > > And there have been nearly two months of mostly silence on the point. > (Thanks to Steve and Arturo for their replies.). > > > If the working group does not reject the approach the authors suggest by > 13 Dec 2013, the authors should proceed with submission of a new version = of > draft-ietf-sidr-multiple-publication-points that meets the first proposal= : > > > - A "6490-bis" document that obsoletes RFC 6490 with the addition of > multiple operators in section 3 of the current document. > > > and submission of an individual draft for consideration of the working > group that meets the second proposal: > > > - A new BCP/Informational document on best practices when RPKI > certificates include multiple repository operators for the same materials= . > > > --Sandy, speaking as wg co-chair > > ------------------------------ > *From:* sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Roque > Gagliano (rogaglia) [rogaglia@cisco.com] > *Sent:* Monday, October 14, 2013 3:41 PM > *To:* sidr wg list > *Subject:* Re: [sidr] possible interim meeting for > draft-ietf-sidr-multiple-publication-points > > Dear Working Group: > > The co-authors of the multi-publication points document would like to > propose a new course of action to the WG referring to this document. > > Since its initial submission, the document addresses two problems > related to the support of multiple operators in RPKI: > i)- Multiple Operators support in TAL files (Section 3 of current > document) > ii)- Multiple Operators support in Certificates (Section 4 of current > document) > > Today, we believe that the two problems are very different. On one side > point i) could be quickly solved by the WG by updating or obsoleting RFC > 6490 with the changes proposed in Section 3 of the document. We have show= n > in Berlin that changes to RPs should be very small and that "some" (and I > say so because in some cases it was accidental) backward compatibility > exists with most popular RPs. > > However the second point ii) while it does not require changes to > existing standard document but rather a "BCP" document, it does require > much more research. While we go down to the RPKI hierarchy, we need to > understand how multiple operators may create transient states and how RPs > will typically react to these. Some of the questions to answer were raise= d > at the meeting and recently in the WG mailing list. > > Our proposal to the group is to split the current content in the > document in two documents: > - A "6490-bis" document that obsoletes RFC 6490 with the addition of > multiple operators in section 3 of the current document. > - A new BCP/Informational document on best practices when RPKI > certificates include multiple repository operators for the same materials= . > > We look forward to hearing from you, > Regards, > > Roque + Carlos + Terry > > > On Oct 2, 2013, at 9:58 AM, Roque Gagliano (rogaglia) > wrote: > > Thanks Sharon for your email and analysis. These points are some of the > points raised during our last meeting. > > I personally believe that the non-TAL work requires more research > activity and I guess from your email that you have an interest in this ar= ea > :-). > > Regards, > Roque > > Hi Roque, > > As you work on this, I wanted share some observations made by my colleagu= e > here at BU, Ethan Heilman. He read the draft in detail and had a two > suggestions and one question, see below. > > Sharon > > > *Suggestion 1: * > > > Section 4.1 of the draft says: =93If the connection to the preferred URI > fails, the RP SHOULD fetch the repository objects from the next URI of > preference." > > > We suggest that the failover logic be extended to include *validation*fa= ilures as well as > *connection* failures (similar to the logic for TALs). That is, when > RPKI-validation generates a warning, an RP should fail over to another > publication point. These warnings could be generated by stale manifests, > manifest errors (http://tools.ietf.org/html/rfc6486), > expired certs, missing ROAs, and other validation failures. We call this > failover mode FO-Corrupt (Failover On Corruption) as opposed to the curre= nt > failover mode FO-Connect (Failover On Connection failure) in the draft. = Here=92s > why we suggest FO-Corrupt: > > > *1) *Multiple publication points using the FO-Connect policy > increase the attack surface, while multiple publication points using the > FO-Corrupt policy decrease the attack surface. With FO-Connect, > corruption failures in a given publication point will directly affect RPs > that select that publication point. Meanwhile, under FO-Corrupt, a > corruption failure must occur on *all * publication points before it > affects RPs; each additional publication point adds an additional barrier > to an attacker that seeks to corrupt objects. This also allows operators = to > raise the cost of an attack by adding publication points using diverse > software and operating systems. Importantly, missing or corrupted RPKI > objects can cause routes to become classified as invalid, and therefore b= e > less preferred -- I provide examples of this happening in the attached PD= F > =96 so if some of the publication points contain uncorrupted objects, it= =92s > important to ensure that RP=92s fetch them. > > > *2) *The differences in behavior between TAL failover and RPKI > object failover could cause confusion. FO-Corrupt would provide a more > consistent policy. Compare the quote from Section 4.1 above with the fo= llowing > from Section 3.2: =93If the connection to the preferred URI fail= s > or the fetched certificate public key does not match the TAL public key, > the RP SHOULD fetch the TA certificate from the next URI of preference.= =94 > > *Suggestion 2: * > > > Section 3.2 and 4.1 of the draft suggest three rules to select the URI > of the publication point: > (1). Provided order, "the order provided in the correspondent certificate= " > ---- my reading is that this would be consistent across all RPs. > (2). Random order (selecting randomly from the available list) > (3). RP prioritized order, "a prioritized list of URIs based on RP > specific parameters such as connection establishment delay", this may or > may not be consistent across some subset of RPs. > > > We see the value of giving RP=92s the flexibility to choosing publicatio= ns > points based on their own concerns (delay, jurisdiction, etc.). But rule > (3) seems problematic because it could be exploited by attackers to > predict the order which an RP would fail over from one publication point = to > the next. For example: > *i. *An attacker could target the first publication > point of the list to distribute bad or missing objects, causing all RPs > to get bad information. > *ii. *An attacker who happened to compromise a > publication point that was not the first element of the list, could e.g. > DOS publication points at the top of the list to ensure that RPs would us= e > the attacker=92s publication point. > *iii. *An attacker which could predict the fail over > order could perform a rolling DOS attack attacking the first element, the= n > the second and so on. > > > *Question: * > > Finally, there has been lots of work on fault-tolerant distributed > database systems that allow RPs to resolve inconsistencies between replic= as > of a database. We=92re not experts on these systems, but given that RPs > will download RPKI data relatively infrequently, is this something that > could be considered here? > > > > _______________________________________________ > 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 > > --=20 Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --e89a8f646edd53eecc04ee2134f6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
This is probably a little late, but I support this plan.
Sharon


On Tue, Dec 17, 2013 at 11:17 AM, Murphy, Sandra <Sandra.Murphy@parsons.com> wrote:
No replies, s= o the authors should proceed as suggested.

--Sandy, speaking as co-chair
Fro= m: sidr [sid= r-bounces@ietf.org] on behalf of Murphy, Sandra [Sandra.Murphy@parsons.com]
Sent: Thursday, December 05, 2013 8:05 PM
To: Roque Gagliano (rogaglia); sidr wg list
Subject: [sidr] a new direction for draft-ietf-sidr-multiple-publica= tion-points

The authors made a suggestion (see below) for a new course of action f= or the draft draft-ietf-sidr-multiple-publication-points, splitting the dra= ft into two work items.


And there have been nearly two months of mostly silence on the point. = =A0(Thanks to Steve and Arturo for their replies.).


If the working group does not reject the approach the authors suggest = by 13 Dec 2013, the authors should proceed with submission of a new version= of draft-ietf-sidr-multiple-publication-points that meets the first propos= al:


- A "6490-bis" document that obsoletes RFC 6490 with the add= ition of multiple operators in section 3 of the current document.


and submission of an individual draft for consideration of the working= group that meets the second proposal:


- A new BCP/Informational document on best practices when RPKI certifi= cates include multiple repository operators for the same materials.


--Sandy, speaking as wg co-chair

Fro= m: sidr-boun= ces@ietf.org [sidr-bounces@ietf.org] on behalf of Roque Gagliano (rogaglia) [rogaglia@cisco.com] Sent: Monday, October 14, 2013 3:41 PM
To: sidr wg list
Subject: Re: [sidr] possible interim meeting for draft-ietf-sidr-mul= tiple-publication-points

Dear Working Group:

The co-authors of the multi-publication points document would like to = propose a new course of action to the WG referring to this document.=A0

Since its initial submission, the document addresses two problems rela= ted to the support of multiple operators in RPKI:=A0
i)-=A0Multiple Operators s= upport in TAL files=A0=A0(Section 3 of current document)
ii)-=A0Multiple Operators = support in Certificates (Section 4 of current document)

Today, we believe that the two problems are very different. =A0On one = side point i) could be quickly solved by the WG by updating or obsoleting R= FC 6490 with the changes proposed in Section 3 of the document. We have sho= wn in Berlin that changes to RPs should be very small and that "some" (and I say so because in some case= s it was accidental) backward compatibility exists with most popular RPs.

However the second point ii) while it does not require changes to exis= ting standard document but rather a "BCP" document, it does requi= re much more research. While we go down to the RPKI hierarchy, we need to u= nderstand how multiple operators may create transient states and how RPs will typically react to these. Some of the qu= estions to answer were raised at the meeting and recently in the WG mailing= list.

Our proposal to the group is to split the current content in the docum= ent in two documents: =A0
-=A0A=A0"6490-bis&quo= t; document that obsoletes RFC 6490 with the addition of multiple operators= in section 3 of the current document.
- A new BCP/Informational = document on best practices when RPKI certificates include multiple reposito= ry operators for the same materials.

We look forward to hearing from you,
Regards,

Roque + Carlos + Terry


On Oct 2, 2013, at 9:58 AM, Roque Gagliano (rogaglia) <rogaglia@cisco.com> wrot= e:

Thanks Sharon for your email and analys= is.=A0These points are some of the points raised during our last meeting.

I personally believe that the non-TAL work requires more research acti= vity and I guess from your email that you have an interest in this area :-)= .

Regards,
Roque

Hi Roque,=

As you work on this, I wanted share some observations made by my colleague = here at BU, Ethan Heilman. He read the draft in detail and had a two sugges= tions and one question, see below.

Sharon

=A0

Suggestion 1:

=A0

Section 4.1 of the draft says: =93If the connection to the preferred URI f= ails, the RP SHOULD fetch the repository objects from the next URI of preference."

=A0

We suggest that the failover logic be exten= ded to include validation failures as well as connection failures (similar t= o the logic for TALs). That is, when RPKI-validation generates a warning, a= n RP should fail over to another publication point. These warnings could be= generated by=A0stale manifests, manifest errors (http://tools.ietf.org/html/rfc6486), expired certs, missing ROAs, and other validation failures. We call this f= ailover mode FO-Corrupt (Failover On Corruption) as opposed to the current = failover mode FO-Connect (Failover On Connection failure) in the draft. =A0Here=92s why we suggest FO-Corrupt:

=A0

1)=A0=A0=A0=A0=A0 Multiple publication points using the FO-Connect policy increase the at= tack surface, while multiple publication points using the FO-Corrupt policy= decrease the attack surface. =A0With FO-Connect, corruption failures in a given publication= point will directly affect RPs that select that publication point.= =A0 Meanwhile, under FO-Corrupt, a corruption failure must occur on a= ll publication points before it affects RPs; each additional publication point= adds an additional barrier to an attacker that seeks to corrupt objects. T= his also allows operators to raise the cost of an attack by adding publicat= ion points using diverse software and operating systems.=A0 Importantly, missing or corrupted R= PKI objects can cause routes to become classified as invalid, and therefore= be less preferred -- I provide examples of this happening in the attached = PDF =96 so if some of the publication points contain uncorrupted objects, it=92s important to ensure that RP=92s= fetch them.

=A0

2)=A0=A0=A0=A0=A0 The differences in behavior between TAL failover and RPKI object failov= er could cause confusion.=A0 =A0=A0FO-Corrupt would provide a more consistent policy= .=A0 =A0Compare the quote from Section 4.1 above with the f<= span style=3D"font-size:12pt">ollowing from Section 3.2: =A0=A0=A0=A0=A0=A0=A0=A0 =93If the connection to the preferred URI fails or the fetched=A0certifica= te public key does not match the TAL public key, the RP=A0SHOULD fetch the = TA certificate from the next URI of preference.=94
=A0
Suggestion 2:

=A0

Section 3.2 and 4.1 of the draft sugg= est three rules to select the URI of the publication point:
(1).=A0Provided order, "the order provided in the correspondent certif= icate" ---- my reading is that =A0this would be consistent across all RPs.
(2). Random order (selecting randomly= from the available list)
(3).=A0RP prioritized order,=A0"= a prioritized list of URIs based on RP specific=A0parameters such as connec= tion establishment delay", this may or may not be=A0consistent=A0acros= s some subset of RPs.=A0

=A0

We see the value of giving RP=92s the= flexibility to choosing publications points based on their own concerns (d= elay, jurisdiction, etc.).=A0 But rule (3) seems problematic because it could be exploited b= y attackers to predict the order which an RP would fail over from one publi= cation point to the next. For example:
i.=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 An attacker could target the first publication point of the list=A0to=A0distribute bad or missing objects, c= ausing all RPs to get bad information.
ii.=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 An attacker who happened to compromise a publication point that was not= the first element of the list, could e.g. DOS publication points at the to= p of the list to ensure that RPs would use the attacker=92s publication point. =A0
iii.=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 An attacker which could predict the fail over order could perform a rol= ling DOS attack attacking the first element, then the second and so on.

=A0

Question:=A0
=A0
Finally, there has been lots of work = on fault-tolerant distributed database systems that allow RPs to resolve in= consistencies between replicas of a database.=A0 We=92re not experts on these systems, but given that RPs will downlo= ad RPKI data relatively infrequently, is this something that could be consi= dered here?
<examples.pdf>

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


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




--
Sharon G= oldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
--e89a8f646edd53eecc04ee2134f6--